File name conversion

ABSTRACT

File name conversion method, and apparatus, for converting a first file name that can be distinguished by a given operating system into a second file name that can be distinguished both by the given operating system and other operating systems. The method and apparatus insure that the first and second file names do not already exist on an associated recording medium prior to recording the first file name on the recording medium and prior to converting the first file name to the second file name. Also provided is a recording medium on which is recorded a file conversion program for converting the first file name to the second file name and for searching whether or not the file names exist on the recording medium.

TECHNICAL FIELD

The present invention relates to an information processor, a method ofinformation processing, and a recording medium recorded a file nameconversion program thereon, which are suitably applied to have filenames recorded, for example, on a write-once disc recording mediumaccessed by a plurality of operation system.

PRIOR ART

Conventionally, as operation systems (OS) for computers, there are, forexample, System 7.5 (trademark) for Macintosh, MS-DOS (Microsoft DiskOperating system) (trademark) and Windows (trademark) of Microsoft, Unix(trademark), and so on which have their own specifications. Filescreated on each of the plurality of operating systems are mutuallyaccessible among these operating systems.

However, when a file name is to be set to a file under the control of acertain operating system, the operating system requires a kind ofpermitted characters and a limited number of characters limited by itsown specifications as well as predetermined attributes given to thefile, as shown in FIG. 46. For this reason, for reading a file managedby an operating system (A) from a computer managed by another operatingsystem (B), the computer requires the user to somehow convert the fileso as to be readable on the operating system (B), so that the laboriousconversion is forced to the user.

For example, comparing the specifications for a file name provided bySystem 7.5 of Macintosh and MS-DOS of Microsoft, System 7.5 of Macintoshallows to designate a file name up to a maximum of 31 characters, whileMS-DOS of Microsoft only allows to designate a file name up to a maximumof eight characters and additional three characters of extension.

The difference in the specifications regarding to a file name betweenthe two operating systems causes the inability of MS-DOS to manage afile given a name such as "abcdefghijklmnopqrstuvexyz" on System 7.5which is the operating system of Macintosh, as illustrated in FIG. 47.As a result, although a file name of 31 characters may be used on System7.5, a file must be given a name of eight characters and an extension ofthree characters also on System 7.5 only for reading the file on acomputer running MS-DOS, thus forcing a significant inconvenience to theuser.

As described above, the conventional file management method individuallymanages files created on a plurality of registered different operatingsystems without considering differences in the specifications amongthese operating systems, so that the user must take part in the filemanagement. However, a problem arises that the user cannot create a filecommonly usable among a plurality of operating systems unless he knowsthe difference in the specifications of the respective operatingsystems.

In addition, even the same operating system may give rise to a problemwhen it has different versions. For example, even if a Japanese filename can be given to a file on a version of an operating system whichsupports display in Japanese language, the Japanese file name cannot bereferenced on a different version of the same operating system whichdoes not support a Japanese environment or a version which does not havea function of displaying Japanese characters. Thus, even under the sameoperating system, the user suffers from complicated handling of filenames. Specifically, file names must be previously unified in a singlecharacter set such as alphabet or the like in consideration of languagessupported by different versions of the same operating system.

Further, the respective operating systems may set identical attributesto files but in a different management method. Thus, even if a write toa file is disabled on a certain operating system, a write to the filemay be enabled on a different operating system.

The present invention has been made in view of the problems mentionedabove, and its object is to propose a recording/reproducing apparatusand a file management method therefor which facilitate the filemanagement among different operating systems.

DISCLOSURE OF THE INVENTION

The present invention is relates to an information processing apparatushaving a recording medium recorded file names thereon and working by atleast first operating system, which provides a file name conversionmethod for converting a first file name which can be distinguished bythe first operating system to at least second file name which can bedistinguished by a second operating system, comprising a step fortransferring the first file name from the first operating system, afirst same file name searching step for searching whether or not thereexists the first file name on the recording medium on the firstoperating system, a first file name writing step for writing the firstfile name on the recording medium in the case where no same file name isfound at the first file name searching step, a first file nameconversion step for converting the first file name to a third file namein correspondence to a second operating system, a second same file namesearching step for converting the file name in conformity with thesecond operating system and searching whether or not the file nameexists on the recording medium, and a recording step for recording thethird file name as a second file name on the recording medium in thecase where no same file name is found at the second same file namesearching step.

Further, the present invention provides storing means for storing thefirst operating system, inputting means for inputting a file name fromthe first operating system, first same file name searching means forsearching whether or not there exists the first file name on therecording medium on the first operating system, first file name writingmeans for writing the first file name on the recording medium in thecase where no same file name is found in the first file name searchingmeans, first file name conversion means for converting the first filename to a third file name in correspondence to a second operatingsystem, second same file name searching means for converting the filename in conformity with the second operating system and searchingwhether or not the file name exists on the recording medium, andrecording means for recording the third file name as a second file nameon the recording medium in the case where no same file name is found atthe second same file name searching means.

Further, the present invention relates to an information processingapparatus having a recording medium recorded file names thereon andworking by at least first operating system, the recording medium beingrecorded a file name conversion program thereon for converting a firstfile name which can be distinguished by the first operating system to atleast second file name which can be distinguished by a second operatingsystem, wherein the program comprising a step for transferring the firstfile name from the first operating system, a first same file namesearching step for searching whether or not there exists the first filename on the recording medium on the first operating system, a first filename writing step for writing the first file name on the recordingmedium in the case where no same file name is found at the first filename searching step, a first file name conversion step for convertingthe first file name to a third file name in correspondence to a secondoperating system, a second same file name searching step for convertingthe file name in conformity with the second operating system andsearching whether or not the file name exists on the recording medium,and a recording step for recording the third file name as a second filename on the recording medium in the case where no same file name isfound at the second same file name searching step.

According to the present invention, in an information processingapparatus for accessing a file recorded on a recording medium inconformity to specifications defined by a plurality of operatingsystems, means for converting a first file name based on thespecifications of an operating system used for file creation/file namechange to a second file name based on the specifications of an operatingsystem used for accessing the file is provided for all of the pluralityof operating systems, thereby file accesses among a plurality ofdifferent plurality of operating systems can be realized.

Also, according to the present invention, a file name converting step isprovided for converting a first file name set on any of the plurality ofoperating system to second file names corresponding to thespecifications of all of the plurality of operating systems at the timeof accessing a file recorded on a recording medium in conformity tospecifications defined by the plurality of operating systems. Thereforeit becomes possible to simplify the file access among a plurality ofdifferent operating systems having different specifications.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram showing the whole configuration of a CD-R discapparatus according to the present invention.

FIG. 2 is a block diagram showing the configuration of CDRFS accordingto the present invention.

FIG. 3 is a schematic diagram explaining management of a plurality ofvirtual address space according to sequence manager SQM.

FIG. 4 is a schematic diagram explaining management structure by B*tree(B Star-tree).

FIG. 5 is a schematic diagram explaining management structure by B*tree(B Star-tree).

FIG. 6 is a schematic diagram showing an example of a correspondence

FIG. 7 is a schematic diagram showing node table.

FIG. 8 is a schematic diagram explaining maximum number of blocks.

FIGS. 9(A) and 9(B) are schematic diagrams explaining how a data blockis updated.

FIG. 10 is a table used for explaining the structure of a B*Tree indexnode.

FIGS. 11(A) to 11(D) are schematic diagrams explaining renewal of thedata blocks.

FIG. 12 is a schematic diagram showing the structure of PVD.

FIG. 13 is a schematic diagram showing the structure of super block.

FIG. 14 is a schematic diagram showing the structure of super block listentry.

FIG. 15 is a schematic diagram showing the structure of tag entry.

FIG. 16 is a schematic diagram showing the structure of node table.

FIG. 17 is a schematic diagram showing the structure of a B*Tree (BStar-tree) index node.

FIG. 18 is a schematic diagram showing the structure of index record.

FIG. 19 is a schematic diagram showing the structure of a sequenceB*Tree (B Star-tree) leaf node.

FIG. 20 is a schematic diagram showing the structure of extent record.

FIG. 21 is a schematic diagram showing the structure of a directoryB*Tree (B Star-tree) leaf node.

FIG. 22 is a schematic diagram showing the structure of directory recordarea.

FIG. 23 is a schematic diagram showing the structure of directoryrecord.

FIG. 24 is a schematic diagram showing the structure of directory recordkey.

FIG. 25 is a schematic diagram explaining the kinds of types.

FIG. 26 is a schematic diagram showing the structure of file directoryrecord.

FIG. 27 is a schematic diagram showing the structure of directorydirectory record.

FIG. 28 is a schematic diagram showing the structure of link directoryrecord.

FIG. 29 is a flowchart showing flash all operation.

FIGS. 30(A) to 30(C) are schematic diagrams explaining the rewritingoperation.

FIG. 31 is a schematic diagram showing the structure of file entry.

FIG. 32 is a flowchart showing the determination procedure of the filename conversion method.

FIG. 33 is a flowchart showing the determination procedure of the filename conversion method.

FIG. 34 is a flowchart showing the determination procedure of the filename conversion method.

FIG. 35 is a flowchart showing the search procedure used in the filename conversion method.

FIG. 36 is a flowchart showing the search procedure used in the filename conversion method.

FIG. 37 is a schematic diagram explaining file name conversion.

FIG. 38 is a schematic diagram explaining file name conversion.

FIG. 39 is a schematic diagram explaining file name conversion.

FIG. 40 is a schematic diagram explaining file name conversion.

FIG. 41 is a schematic diagram explaining file name conversion.

FIG. 42 is a schematic diagram explaining file name conversion.

FIG. 43 is a schematic diagram explaining generation of the search key.

FIG. 44 is a schematic diagram explaining file name conversion.

FIG. 45 is a schematic diagram explaining conventional file access.

FIG. 46 is a schematic diagram explaining limitation of the file name.

FIG. 47 is a schematic diagram explaining file access.

BEST MODE FOR CARRYING OUT THE INVENTION

In FIG. 1, 1 generally shows a CD-R disc device containing aninformation processing section 4 for processing a data to be written ona CD-R disc DISC or a data read out from the CD-R disc DISC, a displayunit 2 comprising such members as a cathode ray tube or a liquid crystaldisplay for supplying the user with processed data, processing state ofthe information of the information processing section 4, an input device3 comprising a keyboard and the like for inputting data to theinformation processing section 4, and a CD-R drive device 5 for writingin and reading out data to and from the CD-R disc DISC.

The information processing section 4 has respectively a CPU (CentralProcessing Unit) 6 for managing entire operation of a system, a RAM(Random Access Memory) 7 for temporarily storing all kinds ofinformation and various programs, a ROM (Read Only Memory) 8 in which abasic program necessary for the CPU 6 to operate is stored, aninput/output (I/O) circuit 9 for outputting information to the displayunit 2, an input/output (I/O) circuit 10 for capturing information fromthe input device 3, a hard disk drive (HDD) 11 for accessing a hard diskin which various programs are stored, an interface (I/F) circuit 12 foraccessing the hard disc drive 11, and an interface (I/F) circuit 13 foraccessing the CD-R drive 5. Incidentally, the RAM 7 functions as a cachebuffer besides a simple memory.

In the information processing section 4 having the aforesaid structure,the CPU 6 reads out program of the file system for CD-R (CDRFS: CompactDisc Recordable File System) from the hard disk 11 via the interface(I/F) 12 based on the program stored in the ROM 8, and then stores it inthe RAM 7. The CPU 6 then starts CDRFS read out so as to start theentire system.

In order to record data in the CD-R disc DISC in the CD-R disc device 1started up, the CPU 6 divides the data made by the user into blocksaccording to a predetermined format under the control of CDRFS. Then theCPU 6 transmits the divided data and an instruction to the CD-R drive 5so as to write the data via the interface circuit 13. When receiving theinstruction, the CD-R drive 5 sequentially records the data for the dataunit referred to as packet on the CD-R disc DISC.

In addition, when the data recorded in the CD-R disc DISC is read out,the CPU 6 of the information processing section 4 gives a readinginstruction to the CD-R drive 5 via the interface circuit 13. Whenreceiving the instruction, the CD-R drive 5 accesses the CD-R disc DISCso as to read out the data recorded for packet, and then transmits thedata to the RAM 17 via the interface circuit 13.

FIG. 2 shows the entire structure of a software SW by which it seems asif the CD-R disc DISC is a recording medium capable of rewriting to theuser. The instruction from the user input via I/O is interpreted in anapplication software AP and an operating system OS, and the instructionis delivered to a file manager FLM of the file system for CD-R CDRFS.

The file system CDRFS comprises the file manager FLM constituting upperlayer part and a virtual device manager IMM constituting lower layerpart. The file manager FLM manages directories and files. Thus, when theoperating system OS sends, for example, overwriting instruction to thefile manager FLM, the file manager FLM specifies correspondent virtualaddress space formed in a virtual device manager IMM based on the filename specified by the instruction.

Here, as shown in FIG. 3, the virtual device manager IMM provides aplurality of virtual address space CVx (CV1, CV2, CV3, . . . ) to thefile manager FLM. Each virtual address space CVx is constituted by adata block array comprising single or a plurality of data block. Thedata block array is referred to as a sequence and corresponds to eachfile managed by the file manager FLM. Accordingly, the file manager FLMspecifies the sequence number of the virtual device manager IMM so as tospecify the virtual address space CVx of the target file. At this time,the file manager FLM can specify each virtual address space CVx in blockunits according to 64-bit logical address called sequence key SQK (FIG.2).

More specifically, in the virtual device manager IMM, each virtualaddress space CVx is managed by the sequence key SQK in block units. Theparticular sequence number for the virtual address space CVx is allottedto the upper 32 bits of the sequence key SQK, and the lower 32 bits arethe sequence block number for specifying blocks BLK (FIG. 3) in thesequence (virtual address space) specified by the upper 32 bits.Consequently, 2³² blocks per one virtual address space (one sequence)can be managed by the sequence block number; namely, each virtualaddress space CVx are adopted to include 232 blocks. Each block BLK is2048 bytes in agreement with CD-R disc format, which enables the virtualdevice manager IMM to manage 8 tera bytes at the most for one sequence,namely one file.

In this manner, in the virtual device manager IMM, each virtual addressspace CVx is provided corresponding to the files so as to constitute afile. Consequently, the virtual device manager IMM can immediatelyaccess the file without executing such complicated procedure asconverting the position of the file to the logical address andretrieving.

Thus, when the logical address directly corresponding to the file shownby the 64-bit sequence key SQK from the file manager FLM is delivered tothe virtual device manager IMM, the sequence manager SQM of the virtualdevice manager IMM (FIG. 2) makes the logical address shown by thesequence key SQK correspond to the physical address on the CD-R disc byusing the retrieving method by means of the multiway tree referred to asB*tree (B Star-tree).

More specifically, as shown in FIG. 4, B*tree (B Star-tree) of thesequence manager SQM has a tree structure which is constituted by anindex node K as an intermediate node (branch) and leaf nodes E, F and Gwhich actually contain the extent (EXTx) showing correspondence betweenthe logical address and the physical address.

Each leaf node E, F, and G stores single or a plurality of extent EXTxrepresenting the relation between the logical address and the physicaladdress LBA, which is shown by the sequence key SQK, in the ascendingorder of the sequence key SQK. More specifically, the extent EXTxmanages (or represents) a block array in which the sequence key SQKcontinues in the ascending order as one unit out of the blockssequentially in array on physical location on the CD-R disc. The extentEXTx consists of the sequence key SQK in the head block of sequentialphysical block managed by the extent EXTx, the physical address LBAcorresponding to the sequence key SQK, and length. The length representsa continuous physical block number represented by the extent EXTx withthe physical address LBA placed at the front in which the length isincluded. Consequently, for example, when the extent EXTx is representedby (0,0 56 5), the physical address LBA on the CD-R disc correspondingto the sequence key SQK (logical address) which is referred to as 0,0 is56, which represents that the data represented by the extent continuesfive blocks with the physical address LBA (=56) placed at the head onthe CD-R disc.

These five data blocks managed by one extent EXTx is written on physicalareas which are continuous on the CD-R disc so that it is possible toavoid an increase in the number of extent EXTx which constitutes anelement of an address conversion table of the logical address and thephysical address by recording data of the same file on the continuousphysical address LBA. In actuality, when an attention is paid to thefact that the probability is high that the same file is processed in acontinuous manner, continuous block of the sequence key SQK iscontinuously written on the physical position on the CD-R disc with theresult that the number of the extent EXTx itself which is an elementconstituting a management structure of the sequence manager SQM can bereduced. For example, when the extent EXTx is (0,0 56 5), the data (forexample, two blocks) having the same sequence number (file) iscontinuously written, the extent EXTx (0,0 56 7) is provided with theresult that the extent EXTx as the management data does not increase.

In FIG. 4, in an index node D constituting the intermediate node ofB*tree (B star-tree), the sequence key SQK (key1, key2, key3, . . . ) ofeach head extent information EXTx of each of the corresponding leafnodes E, F or G is stored together with the node number. When thesequence keys (key1, key2, key3, . . . ) are designated, the leaf nodesE, F or G corresponded by the node number are read out from the physicaladdress LBA on the CD-R disc by referring to the node table (FIG. 5).

Consequently, when the sequence key SQK is designated, the sequencemanager SQM searches the head key (sequence key SQM) in a range in whichthe sequence key SQK is included from the index node D. For example,when the target sequence key SQK is a value between the first sequencekey key1 and the second sequence key key2 stored in the index node D,the sequence manager SQM selects the leaf node E starting from theextent EXT11 having the first sequence key SQK key1 so as to search theinside of the leaf node E sequentially. In this manner, a plurality ofextent nodes EXTx in each of the leaf nodes E, F and G are arranged inthe ascending order of the sequence number so that the physical addressLBA of the data array designated by the desired sequence key SQK easilyby using the method of B*tree (B star-tree).

For reference, FIG. 5 shows a searching method by means of the realB*tree (B star-tree) so that the physical address LBA (H, I, J, . . . )on the target CD-R disc is searched from the super block (referred to asSVD) A, the node table (Node Table) B, the index node D and leaf nodesE, F and G which are recorded on the CD-R disc. In other words, thesequence manager SQM refers to the node table B on the CD-R disc on thebasis of the physical address LBA on the node table B which is recordedin the super block. At the same time, the sequence manager SQMcalculates the physical address LBA of the index node D from the nodenumber of the node table B designated by the root node number which isrecorded in the super block. As a consequence, the sequence manager SQMcan refer to the index node D on the CD-R disc so that the node numbercorresponding to the desired sequence key SQK in the index node D, asdescribed above with respect to FIG. 4. In this index node D, the nodenumber corresponding to the sequence key SQK is read out so that theleaf nodes E, F and G corresponding to the node number read out thephysical address LBA in the node table B. As a consequence, the targetleaf nodes E, F and G can be read out from the CD-R disc so that theextent EXTx corresponding to the sequence key SQK designated at thistime can be read out. With this extent EXTx, it is possible to obtainthe position (H, I, J, . . . ) on the CD-R disc in the target data blockline with this extent EXTx.

For reference, FIG. 6 shows an example of a correspondence relationbetween the sequence number and the physical address LBA. These fourcorrespondence relations can be represented by one extent EXTxrepresented by the sequence number (123456781h), LBA (1000h), and thelength. Each management data constituting B*tree (B star-tree) isrecorded on the CD-R disc with the result that there arises a need ofrewriting data along with the renewal of the content. Consequently, thecorrespondence table between the logical address and the physicaladdress LBA and the management structure thereof are provided withrespect to the data block constituting B*tree (B star-tree). In DCRFS,the 32 bit-long logical address referred to as the node number asmentioned in regard to FIG. 5 is attached to the block constitutingB*tree (B star-tree) so as to manage the correspondence table betweenthe logical address and the physical address as an array table in whichthe logical address is used as a subscript.

FIG. 7 shows an example of a node table which shows that B*tree (Bstar-tree) of the node number "0" is recorded on the position where thephysical address LBA is located at a position of "30". Two data areattached in addition to the array table of the node table. In otherwords, the "number of entry" designates the number of elements in thearrangement whereas "free" shows the head of the used elements in thearrangement. The list of unused elements refers to the managementmechanism of the unused element in the arrangement. With the mechanism,the reuse of the arrangement element can be simplified. The content ofthe last unused elements contains the subscript of the next unusedelement in place of the block address. In this example, table 2 isplaced at the head of the unused element list followed by the followingtable 4 and table 1.

The node table is constituted so that a mechanism for managing the nodetable is omitted by recording the node table on a continuous area on theCD-R disc. In the case where B*tree (B star tree) is changed and theblock constituting B*tree (B star tree) is rewritten, the renewed nodetable is written on the CD-R disc. For example, when the maximum numberof the block number of B*tree (B star tree) required for managing onegiga byte-long data becomes 8095 blocks as shown in FIG. 8 because it isfavorable to consider that each extent EXTx refers to one block and onlya half of each node is used. Since four bytes are required in the arraytable having the logical address as the subscript, the size of the tablewill be 16 blocks as shown in the following equation:

    8095 block×4 byte+2×4 byte=32388 byte=15.8 block≈16 block                                                     (1)

In the case where one giga space is managed, it can be seen that thecontinuous area required as a management table of B*tree (B star tree)is 16 blocks at most. In the CDRFS, a packet comprising 32 blocks isused as a recording unit for recording on the CD-R disc. The node tablecomprising 16 blocks at most is housed in one packet. Consequently, inthe CDRFS this node table is housed together with other managementinformation in the last packet which is written in the CD-R disc at thetime of the flash operation which will be described later.

In this manner, in the CDRFS, the logical and physical addressmanagement mechanism of the data block has a dual structure comprisingB*tree (B star tree) and the node table. The reason for constitutingsuch a dual structure is that when only the logical and physical addressmanagement mechanism by means of a simple array table such as the nodetable is used, a large continuous area is required for the display. Forexample, when the case of the management of one giga space like theaforementioned example is considered, 1024 blocks of continuous area isrequired as shown in the following equation:

    1×2.sup.20 kbyte/2 kbyte×4/2048 kbyte=1024 block(2)

Furthermore, when an attempt is made to manage one giga space only withB*tree (B star tree), the node of B*tree (B star tree) is referred towith the physical address LBA with the result that the rewriting of thereference affects the node of other B*tree (B star tree) every time thenode of B*tree (B star tree) is renewed. Consequently, in the CDRFS, thelogical and physical address management mechanism has a dual structurecomprising B*tree (B star tree) and the node table.

Thus, in the sequence manager SQM, when the physical address LBM havingthe sequence recorded is obtained from the searching method (B*tree (Bstar tree)) described above with respect to FIGS. 4 and 5, the physicaladdress LBA is delivered to the cache manager CAM shown in FIG. 2together with the sequence key SQK.

The cache manager CAM reads and writes data from the CD-R disc of thedata block corresponding to the designated physical address LBA via acache buffer referred to as cache block. In other words, the designatedphysical address LBA and the sequence key SQK are delivered to rewritedata, the cache manager CAM determines whether or not the data blockrepresented by the designated physical address LBA is already present inthe cache buffer. Here, when a negative result is obtained, the cachemanager CAM reads data from the block (cache block) in the cache buffer,and stores the data in the block in the cache buffer so as to allocatethe temporary physical address (Temporary LBA) to the housed data block.In this manner, the sequence manager SQM can access the data blockwithout considering as to whether the position of the physical addressis real or temporary by managing the address with the temporary physicaladdress (Temporary LBA).

Furthermore, at this time, when the cache manager CAM memorizes thesequence key SQK (delivered from the sequence manager SQM) with respectto the data block to deliver the data pointer with respect to the cacheblock having the block data housed and the temporary physical address tothe sequence manager SQM. The sequence manager SQM registers thecorrespondence relation between the temporary address (Temporary LBA)and the sequence key SQK in B*tree (B Star-tree).

At the same time, the data pointer of the cache block delivered from thecache manager CAM is delivered from the sequence manager SQM to the filemanager FLM so that the data designated by the user is renewed. The datablock which is rewritten in this manner is delivered to the cachemanager CAM so that the block is managed as a renewed block which iscalled dirty block in the Write Cache Block which comprises a high speedmemory. At this time, the dirty block is either renewed or created onlyin the cache buffer and is not yet recorded in the CD-R disc.Consequently when the dirty block reaches a predetermined number (32blocks), the cache manager CAM writes the dirty block on the CD-R discDISC via a device driver as one packet.

In the case where the same data block is renewed with respect to thedata block again before the data is written on the CD-R disc by allowingthe dirty block to remain in the write cache block until one packetportion of the dirty block is detained, only the data in the cachebuffer (namely, writing of a new physical address LBA) is rewritten sothat the renewal of data on the CD-R disc can be avoided.

The aforementioned explanation is concerned with a processing forrewriting the data block which exits already on the CD-R disc. The filemanager FLM rewrites data while looking at only the temporary address bymeans of the temporary device manager IMM (FIG. 2). Consequently, evenwhen a write once type CD-R disc is used as a recording medium, the filemanager FIM can rewrite data in the temporary address space like anoperation with respect to the rewritable media.

On the other hand, in the case where data block is newly generated, thesequence manager SQM requests the cache manager CAM to generate a blockby delivering the sequence key SQM of the block to be generated. Thecache manager CAM allocates the block in the cache and allocates atemporary physical address (Temporary LBA) to deliver the address to thesequence manager SQM. At this time, the sequence key SQK delivered tothe cache manager CAM from the sequence manager SQM is memorized in themanagement table of the cache buffer in the cache manager CAM and thesequence key SQK is used at the time of the writing operation on theactual CD-R disc. The sequence manager registers the correspondencebetween the sequence key SQM of the block which is to be generated andthe physical address brought back from the cache manager CAM in themanagement structure comprising B*tree (B star tree).

Furthermore, on the other hand, in the case where the data block iserased, the sequence manager SQM determines the physical address of thedesignated sequence key from B*tree (B star tree) to designate theensure to the cache manager CAM. The cache manager CAM performs noprocessing when the block of the physical address LBA does not exist inthe cache buffer. On the other hand, in the case where the block of thephysical address LEA exists in the cache buffer, the cache manager CAMnullifies the cache block (namely, the block in the cache buffer managedby the cache manager CAM). Then, lastly, the sequence manager SQM erasesthe entry of the sequence key SQK to be erased from B*tree (B star tree)to complete the erasure thereof.

Here, an operation of writing data of the write cache block on the CD-Rdisc is referred to as a "flash". Firstly, when the sequence manager SQMreceives the flash request from the file manager FLM, or secondly whenthe sequence manager SQM receives the writing request from the cachemanager CAM, the flash operation is carried out.

In the first case, when the flash request is made and the CD-R disc isinserted from the application, the system is completed and the externalfactor constitutes a trigger of the CDRFS. On the other hand, in thesecond case, an internal factor constitutes a trigger thereof. When thereusable block does not satisfy the least number required for ensuringthe operation, this is the case in which the operation of writing on theCD-R disc for ensuring the reliability in the CDRFS.

The case in which the number of reusable blocks in the cache does notsatisfy the least number required for ensuring the operation of theCDRFS refers to a case in which the reusable blocks sufficient forwriting, generating, renewing and eliminating of the sequence blockwhich is a basic operation of the sequence manager SQM are not securedin the cache block. Consequently, when sufficient reusable blocks arenot secured in the cache block, the reusable blocks are secured in theflash operation. Incidentally, the reusable blocks are a general name ofwrite cache blocks (referred to as read cache blocks) obtained bywriting the data of the write cache blocks on the CD-R disc and cacheblocks (referred to as Free Cache Blocks) in which no effective data isstored.

Here, the number of reusable blocks which are required for the operationof the sequence manager SQM will be explained. In other words, when thesequence blocks are read, the target data blocks and the reusable blocksfor storing B*tree (B star tree) management structure for examining thephysical address where these blocks are present are required in thecache buffer. These B star tree blocks are not referred to at the sametime at the time of the retrieval with the result that only one reusableblock is present. Consequently, the maximum value RBCmax of the reusableblocks in the cache buffer required for the reading processing of thesequence blocks will be represented in the following equation:

    RBCmax(N)=N+1                                              (3)

wherein N represents the number of data blocks which are to beoriginally read.

At the time of the generation, renewal of the sequence blocks, unwrittenblocks are assigned in the cache buffer. In actuality, since thesequence manager SQM renews B*tree (B star tree)s, data blocks forstoring the node of B*tree (B star tree)s are generated and renewed sothat the reusable blocks more than the number of the target blocks arerequired in the cache buffer. In addition, there is a possibility thatthe data block is generated along with the renewal of B*tree (B startree) at the time of the erasure work. In this case, the reusable blocksare required.

Furthermore, at the time of the generation of the sequence block, theextent EXTx is generated and is inserted into B*tree (B star tree). Whenthere is no allowance in the leaf node to which the extent EXTx isinserted, the leaf node is divided and one data block is generated for anew leaf node. Furthermore, when no allowance is generated in the indexnode to which the leaf node is inserted at the time of inserting intothe index node the generated leaf node for the division, a new leaf nodeis generated for dividing the index node. In the case where depth ofB*tree (B star tree) is 3, the total volume of data that can be managedcan be represented in the following equation:

    170×170/2×145/2×2=2095250≈2 [Gbyte](4)

in the state in which all the nodes other than the route are written by1/2 in consideration of the least efficient state in which the number ofblocks which one extent EXTx is managed is one. Consequently, in theCD-R disc when the volume is less than 700 megabytes, the route node ofB*tree (B star tree) having the depth of 3 is not divided, the number ofdata blocks which is generated along with the insertion of the firstextent EXTx into B*tree (B star tree) will be 2 at most.

Furthermore, since the index node immediately after the division isembedded up to 2/3 at most, it is required to newly insert 170/3 indicesat least to fill the index nodes. Furthermore, when the adjacent indexnodes are not filled, index nodes are moved to average the number ofrespective indices instead of division. Consequently, the least numberof times of the insertion of the index nodes into B*tree (B star tree)which is required from the generation of the division of the index nodesuntil the next division will be 170/3×2=113. Furthermore, in the case ofthe leaf nodes, the insertion of at least 145/3×2=96 extents EXTx isrequired for generating the next division in the same manner. Thus themaximum value CBCmax of data block number generated by the call of onetime block generation with respect to the sequence manager SQM will berepresented by the following equation:

    CBCmax (N)=N+2(N/96)/113+(N/96)                            (5)

wherein N represents the number of data blocks which are to beoriginally renewed.

On the other hand, in the case of the renewal of the data blocks, thework is the same as the case of the block generation except for the workof removing the extent EXTx. In other words, in the case where one partof the extent EXTx is removed by managing the correspondence relationbetween the sequence key SQK of a plurality of consecutive blocks andthe physical address LBA, the number of the extent EXTx will sometimesincrease by one extent. For example, when the extent EXTx as shown inFIG. 9(A) is present, this extent will be exchanged by two extents asshown in FIG. 9(A) by removing the data block from the extent to renewthe data blocks from the sequence keys "3" to "6". In this manner, whenone part of the extent which is already present is removed, another onesurplus extent may be present. In consideration of this fact, themaximum value MBCmax of the data block number generated by the one timecall of the renewal of the blocks with respect to the sequence managerwill be represented by the following equation:

    MBCmax (N)=N+2+((N+1)/96)/113+((N+1)/96)                   (6)

wherein N represents the number of data blocks which are to beoriginally renewed.

Furthermore, in the elimination of the data blocks, there is apossibility that the leaf nodes are divided when one part of the extentis eliminated. Consequently, the maximum value DBCmax of the data blocknumber generated by the one time call of the elimination of the blockswith respect to the sequence manager SQM will be represented by thefollowing equation irrespective of the number of data blocks to beeliminated;

    DBCmax=2                                                   (7)

Furthermore, in the case where the data size to be treated in one timeoperation is not determined, it sometimes happen that a complicatedcalculation such as equations (3) through (7) is not sometimes required.For example, in the case of Windows 95 (trade name), when the allocationunit is read from the file system with [GetDiskInfo], an access can bemade to the file system in the allocation unit. Consequently, when it issupposed that the allocation unit is set, for example, to 32 blocks, thenumber of data blocks which should be operated at one time with thesequence manager will be less than one packet. Thus the block numberwill be represented by the following equation;

    DBCmax<CBCmax (32)=MBCmax (32)=34 (block)                  (8)

Before the operation of the sequence manager SQM, 34 reusable blocks maybe present in the cache buffer.

A flash operation for writing the data in the write cache block on theCD-R disc DISC will be explained. As shown in FIG. 10, the sequencemanager SQM requests the cache manager CAM to collect n packets of writecache blocks in the cache buffer. The number n of packets in this casedepends on the setting of the cache manager CAM.

The cache manager CAM creates a list of blocks to be written on the CD-Rdisc DISC in accordance with a predetermined priority from among thewrite cache block in accordance with the request at step SP1 of FIG. 10.This priority is determined by using a so-called LRU (Least RecentlyUsed) algorithm in which a priority is given to the block having lessaccess to the target block with the result that cache out block (to bewritten on the CD-R disc) is determined in the order of higher priority.Here, when a vacancy is generated in the packet, the cache manager CAMassigns a dummy block to the vacant area.

The cache manager CAM refers to the cache management table at step SP2with respect to the write cache block which is selected in this mannerso that the block list of the write cache blocks are arranged in orderso that the sequence key SQK is placed in order which corresponds to thewrite cache block. Then at the following step SP3, scheduled physicaladdress (Contact LBA) on the CD-R disc where each block is written fromthe block list is assigned like the write start physical address LBA andthe write start address LBA+1. This scheduled physical address (ContactLBA) will become an actual address (Real LBA) which is established onthe CD-R disc when the writing is normally completed. When the writingis failed, the aforementioned temporary physical address will beprovided.

Thus, at step SP3, a probability will become high that the block of thesame sequence will be arranged on the continuous area on the CD-R discby assigning the writing position to the order of the SQM in order withrespect to each write cache block. As a consequence, the block can becontinuously read from the CD-R disc at the time of reading with theresult that the reading performance will be heightened. At the sametime, an increase in the number of elements of B star tree can beprevented in which physical continuous block of the same sequence(files) are managed with one extent EXTx.

Thus, when the scheduled physical address (Contact LBA) is assigned tothe write cache block at step SP3, the sequence manager SQM receives acorrespondence table of the sequence key SQK and the scheduled physicaladdress (Contact LBA) assigned from the cache manager CAM so that B*tree(B star tree) is renewed at step SP4. In other words, at step SP4, thetemporary physical address (Temporary LBA) of the extent EXTx created byassigning the temporary physical address at the time of the data renewalin advance is replaced with the scheduled physical address (Contact LBA;Temporary Actual address). The scheduled physical address (Contact LBA)is assigned with the sequence key SQK in order so that some extent EXTxis summarized by the execution of a plurality of such renewal therebyreducing the number of the extent EXTx of B*tree (B star tree) as awhole. As a consequence, in some cases, a part of the nodes (leaf nodesand intermediate nodes) which constitute B*tree (B star tree) will beeliminated. Consequently, at step SP5, the sequence manager SQM judgeswhether or not the number of blocks which constitute B*tree (B startree) has been decreased or not. When an affirmative result is obtainedhere, this represents that write cache blocks having a low prioritywhich are not selected by the LRU (Least Recently Used) algorithm at theaforementioned step SP1 in place of the decreased block can be included.At this time, the sequence manager SQM returns to the aforementionedstep SP1 to repeat the selection of the write cache block again.

Thus, by repeating the processing at steps SP1 through SP5 a negativeresult will be obtained at step SP5. The cache manager CAM moves to stepSP6 to send the packet data comprising a plurality of blocks collectedin the write cache buffer to the CD-R disc via a device driver with theresult that the data is written on the CD-R disc in a new writing areain the packet unit.

Here, an writing error to the CD-R disc is generated, an affirmativeresult is obtained at the subsequent step SP7. At this time, thesequence manager SQM and the cache manager CAM moves to step SP8 toperform a physical restoration to the CD-R disc. In other words, in theCD-R disc device, it is stipulated in the specification that the data iswritten in the packet unit. It becomes necessary to embed the packetwith dummy data with respect to the packet in which a writing error isgenerated and the record data is interrupted.

Consequently, the sequence manager SQM and the cache manager CAMrestores incomplete packets with dummy data and record again data thatshould be recorded as the packet with the dummy data. At this time, thephysical address LBA of the data to be written is changed so that thesequence manager SQM and the cache CAM manager returns to theaforementioned step SP1 where the data of the unwritten write cacheblock is collected again and a new scheduled physical address (ContactLBA) is assigned to the new scheduled physical address (Contact LBA).Incidentally, with respect to the packet where the writing is completedbefore the error generation the data included in the packet is alreadychanged into a unrenewed data block called read cache block in the cachebuffer so that the data block does not become an object to berecollected by the write cache block after step S8. Consequently, everytime the packet writing is succeeded, the data scheduled to be written(write cache block) decreases so that all the data blocks will befinally written on the CD-R disc.

Thus, at step SP7, the cache manager CAM change the write cache blockcorresponding to the cache buffer into a read cache block with respectto the packet in which a negative result is obtained (packet in whichwriting has been succeeded). At the following step SP10, the processingat steps SP6 through SP9 is repeated until the result having all thepacket written is obtained.

Here, FIG. 11 shows a recording state of the data onto the CD-R disc. Inthe multi-session packet recording method, a plurality of sessions(Session 1, Session 2, . . . ) are subsequently recorded from the innerperiphery to the external periphery on the CD-R disc in a spiral manner.On the inside of the recording area, a power calibration area (PCA) anda program memory area (PMA) are secured so that information for poweradjustment and management information in each session can be recorded.

Each session comprises a program area in which block data of thesequence (file) created and renewed by the user, and a lead-in area inwhich lead-in information representative of the start of the session andlead-out information representative of the end of the session isrecorded. Incidentally, the lead-in information and the lead-outinformation is to be recorded after one session portion of the file datais recorded in the program area. The information is intended to havecompatibility with the CD-ROM.

As shown in FIG. 11(B), the program area is further divided. In the caseof the 3 data track, the program area is divided into three tracks. Atthis time, the head of each track is provided with an index area (Index)and index information of the track is recorded on this part. Further, asshown in FIG. 11(C), the track comprises a collection of packet whichconstitutes a basic unit of data writing. As shown in FIG. 11(D), thispacket is divided into four parts, a link block, a run in block, a userdata block having user data such as file information or the like and arun out block.

Here, as data to be recorded on the program area shown in FIG. 11(A),information showing a data management structure is present in additionto the block data (user data) of the sequence (file) created by theuser. As this information, there is available a primary volumedescriptor (PVD), a super block, a node table, a B star tree index node,a sequence B star tree index node, and a sequence B star tree leaf node.Incidentally, all the data management structure excluding the node tablehas a size of one block (2048 bytes) and is recorded in the blockboundary. Furthermore, the node table is a variable length datastructure having a size of one block or more and the head of the nodetable starts from the block boundary.

The primary volume descriptor PVD is information which is recorded onthe 16th block from the head of the session. At the head 1152 bytes ofthe 16th block, one which is the same as the 1S09660 PVD is recorded andinformation peculiar to CDRFS shown in FIG. 11 is contained. In the PVDof FIG. 12, the Super Block Search Method shows a position where themost recent super block is stored. In other words, the super block isconstituted so as to be written on the CD-R disc every time the flashall operation is performed. With the Super Block Search Method of thePVD, the latest position can be detected.

For example, in the case of "Search Method=0", it is shown that thesuper block is recorded on the block represented by the "Super BlockLBA". Furthermore, in the case of the Search Method=1, it is shown thatthe super block is represented in the "Last Accessible Block".Furthermore, in the case of the "Search Method=2", it is shown that the"Super Block Serial Number" is recorded at the maximum position out ofthe super blocks recorded on the Super Block Area. Incidentally, "SuperBlock Area" refers to the total blocks sandwiched between the blockrepresented by the Start LBA of Super Block Area and a block representedby the End LBA of Super Block Area.

Furthermore, when the "File System Flag" shown in the PVD of FIG. 12 is0x0001, it is shown that "Addressing Method 11" is used. Furthermore,when "the File System Flag" shown in the PVD of FIG. 12 is 0x0002, it isshown that the "ISO9660 Volume" is hidden so as not to be seen from theCDRFS. Furthermore when the "File System Flag" shown in the PVD of FIG.12 is "0x0003", it is shown that the first track of the session isrecorded with TAO (Track At Once) or a variable length packet.

Furthermore, the Packet Size shown in the PVD of FIG. 12 shows the blocknumber of the user data in the fixed length packet. However, this fieldis effective only when the "Addressing Method II" is used.

Furthermore, the "Volume Capacity" shown in the PVD of FIG. 12 shows thetotal number of blocks which can be recorded on the CD-R disc after theformat. Incidentally, this value is a reference value which is used atthe time of returning the information on the total volume of the CD-Rdisc with respect to the operation system.

Furthermore, FIG. 13 shows a structure of the super block. For example,information representing that the block is a super block is recorded onthe first "Super Block Header". In the case of the "Search Method=1",when the Super Block is not recorded on the "Least Accessible Block", anold "Super Block" is searched on the basis of this Super Block Header.

Furthermore, the "Super Block Flags" represents whether or not dataeffective for the session is recorded or not. "Node Table LBA" shows theblock in which the node table is recorded. When the size of the nodetable is two blocks or more, "Node Table LBA" is sequentially recordedfrom the block represented by the Node Table LBA. Furthermore, the"Previous Super Block" shows the position of the Super Block which hasbeen previously recorded. In the case of the CD-R disc, the data whichhas been previously recorded will not be lost from the disc.Consequently, it is possible to know the state of the past volume bykeeping track of the "Previous Super Block".

The "Sequence B star tree Root Node Number" shows the node number of themanagement structure (Sequence S Star Tree) comprising theaforementioned B Star Tree with respect to FIG. 5. In addition, the"Directory B Star Tree Root Node Number" shows the node number of thenode of the Directory B Star Tree managed by the File Manager FIM. The"Serial Number" refers to a sequential number of the super block.Incidentally, the "Serial Number" of the super block generated at thetime of the format is "0".

Furthermore, the "Super Block List" is a table in which 50 PreviousSuper Blocks LBA" are collected in the past. The "Super Block List"comprises a repetition of Super Block List Entry as shown in FIG. 14.The first entry of the Super Block List shows the super block one blockbefore the super block in which the Super Block List is housed. When thenumber of the past Super Block is less than 50, the entry is filled fromthe bead thereof and the unused entry is filled with "0".

The "Super Block Tag List" is a table of the name label of the pastsuper block. The "Super Block Tag List" comprises a repetition of a tagentry as shown in FIG. 15. In this CDRFS, 24 tags at most can beattached to one CD-R disc. At this time, when the tag is less than 24,the entry is filled from the head and the unused entry is filled with"0".

Furthermore, the Node Table refers to a correspondence table between thenode number of each node of the management table (Sequence B Star Tree)comprising the B Star Tree) and the physical address thereof asdescribed above in FIG. 5. The Node Table has a structure as shown inFIG. 16. This Node Table is recorded sequentially from the head of thedata block. When the Node Table cannot be housed in one data block, asequel to the next data block is recorded.

Furthermore, the index node is a node other than the leaf node of themanagement structure comprising the B Star Tree. Information shown inFIG. 17 is recorded in the index node. The "Number of Record" shown inFIG. 17 shows the number of index records housed in the leaf node.Incidentally, this index record has a structure shown in FIG. 18, andthe index record is sorted in the ascending order of the key and isfilled from the "Index Record [0]" in order to be recorded.

In addition, the sequence B Star Tree Leaf Node refers to the node ofthe B Star Tree for housing the correspondence relation between thesequence key SQM and the physical address LBA, and the Sequence B StarTree Leaf Node has a structure as shown in FIG. 19. The extent EXTx inthis leaf node has a structure shown in FIG. 20, and is sorted in anascending order to be filled from the Extent Record [0] to be recorded.Incidentally, the number of the extents EXTx in the node is recorded inthe Number of Records.

Furthermore, the Directory B Star Tree Leaf Node h is the node of the BStar Tree for housing the file name, the sequence key SQK, acorrespondence relation between the directory name and the directorynumber, and attribute information of the file and the directory, and hasa structure shown in FIG. 21. In the "Node Number" in this leaf node,the "Node Number" of the leaf node added with [0x80000000] is housed.The "Number of Records" shows the number of directory records housed inthis leaf node. "Previous Node Number" and "Next Node Number" show theNode Number of the leaf node having the least key and the leaf nodehaving the largest key. When no target node exists, [0xffffffff] isrecorded. In the Total Size of Record, the total byte number of theIndex Records Offset and the directory record is recorded.

The Directory Record Area is used as shown in FIG. 22. "PosX" isreferred to as "Index Record Offset", and shows the position where thedirectory record is recorded is shown with the byte offset from the headof the directory record area. Incidentally, this "PosX" is one byte.Incidentally, the PosX is sorted in the order of the key held by thedirectory record shown by the PosX. The PosX is filled from the head andis recorded.

"RecX" is a main body of the directory record. The position is notparticularly limited. However, when the algorithm adopted in the CDRFSis used, the directory record which has been recently created as aresult of the processing is housed at a position most adjacent to thehead of the directory area. When the value housed in the "Number ofRecords" is set to "Nrj", an area between "PosNr-1" and "PosNr-2" is anunused area. This area is used for the renewal and the preparation ofthe directory record. Incidentally, the unused area is used from thehead, and the unused area is from the rear in "RecX".

The directory record refers to the correspondence relation between thefile name, the sequence key SQK, the directory name and the directorynumber, and a variable length data for housing the attribute informationof the file and the directory. The directory record has a structureshown in FIG. 23. Incidentally, the directory record is recorded on thedirectory record area described above. The key in the directory recordis assigned to the directory record, and the key is constituted as shownin FIG. 4.

In FIG. 24, the directory number is a number peculiarly attached to eachof the directory. All the directory in the same directory has the samedirectory number. "Hashed Key" refers to a residual obtained when thename of the directory record is divided by the generating function shownby the following equation;

    P(x)=X.sup.16 +X.sup.12 +X.sup.5 +1                        (9)

This "Hashed Key" becomes the same value with respect to the differentname. To avoid this, "Sequential Number" is used in the CDRFS. In thecase where the directory record having an equal directory number and anequal "Hashed Key" despite the name different from the directory recordwhich is to be inserted already exists in the B Star Tree, the CDRFSsets to the Sequential Number of the directory record a number obtainedby adding 1 to the "Sequential Number" of the directory record which isalready present in the B Star Tree.

Furthermore, the size shows a byte number of the directory recordincluding the key and the size itself. Furthermore, the type is a fieldfor showing the type of the directory record. There are five kinds asshown in FIG. 25. Furthermore, apart from this, it is shown that whenthe bit 7 of the type is erected, the directory record is referred tofrom one or more Hard Link Directory Record.

Incidentally, structures of the File Directory Record, the DirectoryRecord and the Link Directory Record are shown in FIGS. 26 through 28.

Data (management information) comprising such B Star Tree is written inthe user data area (FIG. 11) together with the file data (user data) atthe time of writing operation called flash all. In other words, thesuper block contains the physical address LBA of the block housing thenode table, and the route node number of the management structure (FIG.5) comprising the B Star Tree, and is constituted so that the link toall the data on the CD-R disc excluding the PVD begins with the superblock until reaching the file content from the management information.Furthermore, as described above with respect to FIG. 5, the node tableis required to refer to the node of the management structure comprisingthe B Star Tree. Consequently, the Super Block constituting suchmanagement structure is written at the time of the flash all operationto the last block one block before the next time writing position of theuser area. The timing at which the flash all is carried out is when thepredetermined time which is set has elapsed, and more than thepredetermined amount of data is written on the CD-R disc. As aconsequence, management information (super block) is written on the CD-Rdisc in a predetermined interval.

FIG. 29 shows an operation procedure of the flash all. The sequencemanager SQM and the cache manager CAM enters into the processingprocedure from step SP20. At step SP21, a list is created in the samemanner as the case of the flash operation described above in FIG. 10with respect to the write cache block in the case buffer. In otherwords, the sequence manager SQM demands the cache manager CAM to collectall the write cache blocks in the cache buffer. After the cache managerCAM creates a list of all the unwritten cache blocks and dummy blocks asrequired, the cache management table is referred to arrange so that thesequence key SQK is put in an ascending order. The scheduled physicaladdress (Contact LBA) is assigned in an order such as the physicaladdress LBA with which the writing is started from the head block of thelist thus arranged, and the physical address LBA+1 with which thewriting begins.

The sequence manager SQM renews the B Star Tree on the basis of thesequence key SQK and the physical address. The processing up this stepis repeated until the block elimination is generated by the renewal ofthe B Star Tree. Next, at step SP22, the sequence manager SQM demandsthe cache manager CAM to generate the data block for housing the nodeblock and the super block in the same procedure as the normal blockgeneration. As a consequence, the cache manager CAM generates the superblock and the block for the node table in the cache buffer.

Here, for the generation of the block of the node table,"ffffffff00000000(hex)", "ffffffff00000001(hex)" . . . are delivered,and for the generation of the super block, "ffffffffffffffff(hex)" isdelivered as the sequence key SQM. In this manner, by attaching thesequence key SQK the node table, the node table is arranged in acontinuous area at the time of the block arrangement operation, and thesuper block is arranged in the last block of the last packet.

Subsequently, the cache manager CAM creates a list again with respect tothe write cache block at step SP23. In other words, the sequence managerSQM demands the cache manager CAM to collect all the write cache blocksin the cache buffer. When there is a data block which is not sentbefore, the data block is collected again. After a series of processingis performed as usual such as the preparation of the block list by thecache manager, the determination of the physical address LBA and therenewal of the B Star Tree by the cache manager CAM, each content isfilled in the super block and the block for the node table at step SP24.

After this, the data is actually recorded in the packet unit afterpreceding to the step SP25. After the data is all written, the processproceeds to step SP30 thereby ending the flash all operation.Incidentally, since steps SP25 through SP29 are the same as steps SP6through SP10, explanation thereof is omitted.

In this manner, in the flash all operation, the largest value such as[ffffffffffffffff(hex)] is assigned to the super blocks as the sequencekey. On the other hand, such large and continuous values as[ffffffff00000000(hex)], [ffffffff00000001(hex)] and . . . are assignedto the node table as the sequence key. Furthermore, continuous valuessuch as [fffffffe00000000 (hex)], [fffffffe00000001(hex)] and apparentlydifferent from the node table are assigned to the leaf node as thesequence key SQM.

These values are extremely large compared with the sequence key SQM[0000000500000000(hex)], [0000000500000002 (hex), . . . ) which areassigned to the block data (user data) constituting a sequence (file)other than the super block, the node table and the leaf node.Consequently, when the flash operation is carried out with the sequenceblock assigned in this manner, the user data and the managementinformation (super block, node table and the leaf node) is block sorted(rearranged) so that the sequence key SQK is arranged in an ascendingorder. Thus, the user data and the management information issequentially recorded on the CD-R disc in the sorting order. As aconsequence, management information such as super block, the node table,the leaf node and the like to which large sequence key SQM is assignedare written on the last block of the last packet.

In this manner, a reference relation is established only in a directionfrom the block which is written on the CD-R disc later toward the blockwhich is written on the CD-R disc earlier. Consequently, as shown inFIG. 30(A), when an attempt is made to write data in the packet unitsequentially from the left (the CD-R disc on the inner circumference) tothe right (CD-R disc on the outer circumference), a reference relationis established only in one direction so that the packet datab (forexample, the super block) which are about to be written on a newunwritten area refers to the packet data a (for example, node table)which is written on the forward part of the physical address. As aconsequence, in the case where the packet data b is failed to be writtenas shown in FIG. 30(B), only the packet data b which has failed to bewritten may be rewritten as shown in FIG. 30(C). As a consequence, inthe case where it is so constituted that the forward packet data arefers to the backward packet data b, a rewriting operation can beeasily performed at the time of error occurrence as compared with thecase in which it is necessary to rewrite the physical addressinformation of the backward packet data b in the forward packet data ain accordance with the change in the writing position of the backwardpacket data b (to write the forward packet data a in a new unwrittenarea together with the backward packet data b in the case of the CD-R).

Furthermore, in the CDRFS, the flash operation is carried out withoutfail at the time of taking out the CD-R disc from the CD-R driver 5 sothat the super block is written on the last packet. Consequently, whenthe CD-R disc is inserted into the CD-R drive again, the CDRFS retriesthe super block from the outermost circumference. On the basis of themanagement information of the super block described above with respectto FIG. 5, data written on the forward part (inner circumference side)of the super block is referred to. At this time, when the super block isfailed to be written on the last packet, the CDRFS searches a superblock one block before toward the inner circumference sequentially fromthe super block. In this case, it becomes difficult to access the userdata which is written on the super block after the super block one blockbefore. Consequently, with the CDRFS of the invention, the flash alloperation at the time of writing data on the CD-R disc is carried outwhen a predetermined time has elapsed and an amount of data whichexceeds the predetermined amount is written from the cache manager CAMto the CD-R disc. As a result, the super block is written on the CD-Rdisc relatively frequently with the result that even in the case wherethe super block which should exist on the last packet fails to bewritten on the last packet, it becomes possible to avoid the loss of alarge amount of user data by reading the super block one block beforewhich is written relatively near to the target super block.

The CDRFS which operates as described above stores file information suchas file name for each file in the storage area corresponding to the filewhen generating the file. Incidentally the file entry is dealt with asthe file managed at the aforementioned CDRFS. As shown in FIG. 31, thefile entry has an area for recording the size of file entry, a keymanagement area for recording the information on key referred to as"key", and an area referred to as Object Name Area for managing filename.

In the key management area, Directory Number, search key CRC (CyclicRedundancy Check Code), and District Number are recorded. In the ObjectName Area, the file name designated under the operating system OS whichcomes under when the file is generated, the information for managing thefile name, and length of the file name, etc., are stored.

The file name written on the CD-R disc DISC as a file entry is convertedto the file name to which a plurality of operating systems can accessed.Consequently, in the case where the file written in the CD-R disc DISCis accessed through each operating system OS, the CDRFS converts thefile name read out from the CD-R disc DISC to the file name recognizableby the operating system OS used at accessing. Thus the operating systemOS presently being used can recognize the file name on the CD-R discDISC within the language environment.

Here, the describe will be made of the case where a new file name whichcan be accessed through a plurality of operating systems OS(0) to OS(N)registered in the CDRFS is created in accordance with a file nameconversion procedure as shown in FIGS. 32 to 34. In addition, OS(X)represents the operating system OS other than OS(0).

At first, when a command for preparing the file on the CD-R disc DISC isissued via an application software AP, the operating system OS(0) startprocessing the procedure as shown in FIG. 32. At step SP51, theoperating system OS(0) issues the command for preparing the file byusing the designated desired file name. Here, the CDRFS reads the fileentry already written in the CD-R disc DISC on the RAM 7 (FIG. 1). Atstep SP52, the operating system OS(0) retrieves whether or not thereexists the file having same file name as designated under the operatingsystem OS(0) in the file entry on the RAM 7 (FIG. 31) throughout all thefiles on the CD-R disc DISC. Incidentally, the file entry is read outfrom the CD-R disc DISC if necessary and expanded on the RAM 7 under thecontrol of the CDRFS.

As the retrieving method, the CDRFS converts the file name designatedunder the operating system OS(0) to the search key CRC at aforementionedstep SP51. In this case, the file name is converted in accordance withthe predetermined retrieve key conversion method and then top fourcharacters of the converted file name are picked up. Then, charactercodes representing top four characters are divided by a predeterminednumber, so that the search key CRC can be obtained. In this manner, inthe operating system (MS-DOS) in which fewest character number for afile name is set, if the latter four characters out of top eightcharacters in the file name comprising eight characters+three characters(extension) are replaced with the following Distinct Number, theremaining top four characters can be used for retrieving by the searchkey CRC. In this manner, when the search key CRC having the file namedesignated under the operating system OS(0) is obtained, the CDRFS alsoconverts the top four characters of all file names written on the CD-Rdisc DISC out of the file entry to the search key CRC and compares themwith the search key CRC of the file name to be created which isdesignated under the operating system OS(0).

In this manner, one of the file name at least whose search key CRC iscorresponds with the search key CRC of the file name designated underthe operating system OS(0) is retrieved out of the file name alreadywritten on the CD-R disc DISC.

If there exists the one whose search key CRC corresponds, the CDRFSconverts the file name whose search key CRC corresponds to the file namereadable under the operating system OS(0). More specifically, on theCD-R disc DISC, there may exist the file name created another operatingsystems OS(1) to OS(N), which makes it difficult for the operatingsystem OS(0) presently being used to read the file name as it is. Thusthe CDRFS converts (conversion of the number and type of the characters)file name whose search key CRC corresponds out of the file names of thefile entry which are read from the CD-R disc DISC on the RAM 7 to thefile name readable by the operating system OS(0) presently being used.

The file name converted in such manner is compared with the file namedesignated under the operating system OS(0) at aforementioned step SP51.This enables the CDRFS to determine whether or not there exists thecorresponding file name through the operating system OS(0).

If there has already existed the file name same as the one to be createdin the converted file names which can see under the operating systemOS(0) as the result of the retrieving at step SP52, the CDRFS proceedsto step SP53 so as to inform the operating system OS(0) of the existenceof the same file name by delivering the pointer. Then the CDRFS executessuch error process as error display on aforementioned display unit 2 soas to terminate the file name conversion procedures.

Further, if there cannot be found same file name in the file entry asthe file name designated at aforementioned step SP51 through theoperating system OS(0), the CDRFS proceeds to step SP54 so as to writethe file name designated at the operating system OS(0) in storing areain the file entry as Object Name with no change and also write theObject Name in the CD-R disc DISC if necessary. Incidentally, the CDRFSexecutes the file management normally in the virtual address spaceextended on the cache buffer (the RAM 7). Also, in the file nameconversion process, the write-in/read out process of the file name isexecuted to the virtual address space on the cache buffer. If theresidual quantity in the cache buffer is reduced or the CD-R disc DISCis took out from the CD-R drive 5 (FIG. 1), the data in the cache buffer(the file entry, the file management data, etc.) is written in the CD-Rdisc DISC.

Next, the CDRFS proceeds to step SP55 so as to write the number of theoperating system OS(0) presently being used in the storing area referredto as Name Discipline provided in the Object Name Area. Thus the type ofoperating system OS(0) by which the Object Name written in the fileentry is generated is corresponded with the Object Name and managed onthe file entry.

Further, the CDRFS proceeds to step SP56 so as to set Name ConversionFlag provided in Object Name Area of the file entry (FIG. 31) as "1".When the new file name to be created under the operating system OS(X)(=OS(0)) presently being used is converted to the form (Simple Name (X))readable by each operating system OS(1) to OS(N), the name conversionflag decides the necessity of further conversion (namely, whether or notthe same file name exists through each operating system (OS(X)). If itis necessary, the same conversion flag is set as "0"; if it is notnecessary, the same conversion flag is set as "1". In this manner, thename conversion flag is set as "0" when it is necessary. Thus when theaccess to the CD-R disc DISC is done through a new operating system OSwhich has not installed, the flag is set as "0" as the initial status ofthe new operating system OS so that the conversion is always performed.In the case of step SP56, it has been already known that the same filename does not exist through the operating system OS(0) at step SP52.Consequently, conversion is not necessary through the operating systemOS(0) so that the name conversion flag is set as "1".

Further, the CDRFS proceeds to next step SP57 to set HT flag provided inthe object name area of the file entry (FIG. 21) to "1" or "0". The HTflag represents whether or not the file name to be created whichdesignated by the operating system OS(X) (=OS(0)) presently being usedincludes a mark "˜" referred to as Tilda. When the tilda mark is used,"1" is set; when the tilda mark is not used, "0" is set. The HT flag isset for the sake of determination whether or not the file name coincideswith a Distinct Name which will be mentioned later. If the HT flag is"1" (namely, the tilda mark is used), the file name may coincide withthe distinct name; if the HT flag is "0" (namely, the tilda mark is notused), the file name and the distinct name are not same.

Consequently, the processes of aforementioned steps SP51 to SP57 decidethe file name which does not coincide with the other file name on theCD-R disc DISC when under the operating system OS(0) presently beingused.

The CDRFS determines whether or not it is necessary to change the filename decided at steps SP51 to SP57 as described above when seeingthrough the other operating systems OS(1) to OS(N). Then the processesaccording to the result of the determination are executed at theprocesses after step SP58 in FIGS. 33 and 34.

More specifically, the CDRFS start determining whether or not the filename coincides for the other operating system OS(X) (=OS(1)) by settingto X=1. Then the CDRFS proceeds to next step SP59 to create the filename referred to as Simple Name(X) (=Simple Name(1)) as the file namecorresponding to the operating system OS(X) (=OS(1)) from the ObjectName which is set in the file entry at above step SP54.

In the Simple Name(X) (=Simple Name(1)), the character out of thecharacters constituting the Object Name, which is unusable under theoperating system OS(X) (=OS(1)) for present determination, isrepresented by an underline character "₋₋ " (hereinafter referred to asunderbar), and the number of characters of the Object Name is curtailedup to the number acceptable as the file name of the operating systemOS(X) (=OS(1)). Provided that, underbar is included in the number ofcharacters.

For instance, the Object Name set at aforementioned step SP54 is AAA///and the operating system OS(1) is MS-DOS, a slash mark / cannot be usedin the operating system OS(1) so that all the slash mark / is replacedwith the underbar. In addition, a file name permitted on the operatingsystem OS(1) is limited to eight characters plus three characters(extension) at maximum, so that the CDRFS regards top eight charactersof the Object Name and extension (three characters) as the SimpleName(1). For example, if a file name is ABCDEFGHIJK.TXT, Simple Name(1)is reduced to ABCDEFGH.TXT. Incidentally, extension shown in threecharacters below the dot mark represents file type for MS-DOS, by whichthe application soft AP is executed. Consequently, the extension remainsas the Simple Name(1).

As described above, when obtaining the Simple Name(X) (=Simple Name(1))which is created in the form readable by the operating system OS(X)(=OS(1)), the CDRFS proceeds to step SP60 to determine whether or notthe Simple Name (X) (=Simple Name(1)) is used in the other file. Morespecifically, at step SP60, the CDRFS searches whether or not thereexist any files having same file name as the Simple Name (X) (=SimpleName(1)) corresponding to the operating system OS(X) (=OS(1)) in thefile entry read from the CD-R disc DISC on the RAM 7 throughout all thefiles on the CD-R disc DISC. While searching, the CDRFS once convertsall the files on the CD-R disc DISC to the search key CRC and alsoconverts the Simple Name(X) (=Simple Name(1)) to the search key CRC.Then the CDRFS searches the file name in which at least the search keyCRC coincides with the search key CRC of the Simple Name (1). The CDRFSconverts the file name found that the search key CRC coincides to thefile name readable by the operating system OS (X) (=OS(1)), anddetermines whether or not the converted file name coincides with theSimple Name(1). This enables to search whether or not there exists thefile name which coincides with the Simple Name (1) readable by the firstoperating system OS(1) when the file name already written on the CD-Rdisc DISC is converted to the file name readable by the first operatingsystem OS(1).

If a negative result is obtained at step SP60, this means that thereexists no file name coincident with Simple Name (1) when the file nameswritten on the CD-R disc DISC are converted to the file names readableby the first operating system OS(1) so that it is not necessary toconvert the Simple Name (1). At that time, the CDEFS proceeds to stepSP61 to set Name Conversion Flag (1) (NC(1)), which is set correspondingto the first operating system OS(1), to "1".

On the contrary, if an affirmative result is obtained at step SP60, thismeans that there exists the file name coincident with Simple Name (1)when the file names written on the CD-R disc DISC are converted to thefile names readable by the first operating system OS(1) so that it isnecessary to convert the Simple Name (1). At that time, the CDEFSproceeds to step SP62 to set Name Conversion Flag (1) (NC(1)), which isset corresponding to the first operating system OS(1), to "0".

As described above, when the Name Conversion Flag (1) is set at stepsSP61 or SP62, the CDRFS proceeds to next step SP63 to determine whetheror not the value of X is the value N, namely it is below the number of aplurality of operating systems OS(X). If an affirmative result isobtained here, this shows that it is not finished yet to set the NameConversion Flag (X) corresponding to all operating systems OS (X) (OS(1)to OS(N)). At that time, the CDRFS adds 1 to X at step SP64, and thenreturns to aforementioned step SP59 to create the Simple Name (2) whichis readable by new operating system OS(X) (=OS(2) from the Object Nameset at aforementioned step SP54.

The CDRFS executes the processes of aforementioned steps SP60 to SP63also for the Simple Name (2) created as described above. Thereby whenall the file names on the CD-R disc DISC are converted to the file namesreadable by the operating system OS(2), the search is executed aboutwhether or not there exists the file readable by the operating systemOS(2), which coincides with the Simple Name (2). Also, the CDRFS setsthe Name Conversion Flag (2) set corresponding to the operating systemOS(2) to "1" or "0" in accordance with the existence of coincidence.

As described above, the Name Conversion Flag (2) is set corresponding tothe operating system OS(2), the CDRFS adds 1 to X at step SP64 and setsthe Name Conversion Flag (3) corresponding to new operating systemOS(3). In this manner, repeating the procedures of steps SP59 to SP64,the CDRFS searches, in the operating system OS(1) to OS(N), whether ornot the Simple Name (X) created corresponding to each operating systemOS(X) coincides with the file name already written on the CD-R discDISC. Also, the CDRFS sets each Name Conversion Flag (X), which is setrelated to each Simple Name (X) corresponding to each operating systemOS(X), to "1" or "0".

When finishing setting the Name Conversion Flag (X) corresponding to alloperating systems OS(1) to OS (N), the CDRFS obtains a negative resultat step SP63 and proceeds to step SP65 shown in FIG. 34. The processesafter step SP65 shown in FIG. 34 are as follows: based on each NameConversion Flag (1) to Name Conversion Flag (N) set related to eachSimple Name (1) to Simple Name (N), the latter four characters of theSimple Name (X) which is necessary to convert are replaced with thetilda mark ˜ and the number represented by three characters (DistinctNumber), so that the Simple Name (X) is converted to the Distinct Name(X).

First, the CDRFS obtains an initial value of the Distinct Number (DNO)from the search key CRC at step SP65. More specifically, the CDRFSmanages each file name in each number of search key CRC, which lines upthe file names having same search key CRC as the internal managementinformation. This enables to search easily.

Consequently, out of the search key CRC, the CDRFS have the maximumvalue of which the last file name is the Distinct Number out of aplurality of file names having the coincident search key CRC at stepSP60. The value following the maximum value is set as initial value atstep SP65.

The initial value of the Distinct Number (DNO) is set as describedabove, the CDRFS proceeds to succeeding step SP66 to set X=1 which is asthe process to search whether or not there exists the file namecoincident on the operating system OS(X). Moreover, the CDRFS sets thevalue of the number Y for memorize the operating system OS(X) by whichthe search is started. Here, the Number Y is set to "1" same as thenumber X.

The Distinct Name (X) is the file name that, when the Simple Name (X)cannot be used, predetermined number of latter character string of theSimple Name (X) (in this embodiment, four characters) is replaced withthe Distinct Number so as to the file names on the operating system (X)does not coincide with each other. The Distinct Name (X) is used as thefile name for the operating system OS(X). Here, former four charactersremained at replacement is referred to as Distinct String.

All the operating systems OS(X) to which the CDRFS corresponds usecommon Distinct Number. Thus same Distinct String is used in allDistinct Name (X).

Here, the String converted from the Distinct Number is obtained by thefollowing equations:

    If DNO is 0 to 35, ˜m[DNO mod36]                     (10)

    If DNO is 36 to 1331, ˜m[(DNO-36)/36]m[(DNO-36)mod 36](11)

    If DNO is 1332 to 47988, ˜m[(DNO-1332)/1296]

     m[((DNO-1332)-((DNO-1332)mod 1296))/36]

     m[((DNO-1332)-((DNO-1332)mod 1296))mod/36]                (12)

Here, m[X] represents x-th character of the"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ". For example, m[0] represents"0", and m[10] represents "A". Xmod Y represents the remainder when X isdivided by Y.

Next, the CDRFS proceeds to step SP67 to see the Name Conversion Flag(X) (=Name Conversion Flag(1)) of the first operating system OS(X)(=OS(1)) designated at aforementioned step SP66. Being the NameConversion Flag (1) 1 then, which means the operating system OS(1) doesnot need the Distinct Name, it is not necessary to determine whether ornot the Distinct Name coincides. The CDRFS then proceeds to step SP69 toadd 1 to X. At succeeding step SP73, the CDRFS determines whether or notthe value X exceeds the preset number N.

If a negative result is obtained at step SP73, this shows that presetsearch processes corresponding all the operating systems OS(1) to OS(N)is not finished yet. At that time, the CDRFS proceeds to step SP75 tocompare the value X with the value Y. In this case, unfinished searchprocess makes the value X not to coincides with the value Y, so that theCDRFS obtains a negative result and then returns to aforementioned stepSP67 to determine the Name Conversion Flag (2) for next operating systemOS(2).

On the other hand, if an affirmative result is obtained at step SP73,which shows that the preset search processes corresponding to all theoperating system OS(1) to OS(N) are done, the CDRFS proceeds to stepSP74 to set X=1 so as to return the value X to the initial value. Thenthe CDRFS proceeds to step SP75 to compare the value X with the value Y.At that time, the value X is returned to the initial value "1", whichgives the CDRFS an affirmative result, so that the CDRFS proceeds tostep SP76. In this manner, when it is not necessary to convert theSimple Name (X) created corresponding to the operating system OS(X) as aresult of the determination at aforementioned step SP67, it can be foundthat the Simple Name (1) to the Simple Name (N) created corresponding torespective operating systems OS(1) to OS(N) based on the file name(Object Name) to be created in the operating system OS(0) can be used.

Consequently, the CDRFS determines at step SP76 to use the Simple Name(1) to the Simple Name (N) based on the Name Conversion Flag (1) to theName Conversion Flag (N) (=1) which are set corresponding to each SimpleNames, and then finishes the file name conversion processes. Thus thenew file name (Object Name) which is specified by the operating systemOS(0) and written on the file entry and the CD-R disc DISC ataforementioned step SP1 is converted by the CDRFS to the Simple Name (X)readable by all the operating system OS(X) so as to be accessed wheneach operating system OS(1) to OS(N) accesses the file name.

On the other hand, if a negative result is obtained at aforementionedstep SP67, which shows that it is necessary to convert the Simple Name(X) created corresponding to the operating system (X) which is theobject for determination at that time. The CDRFS proceeds to step SP69to generate the Distinct String from the former characters of the SimpleName (X) which are remained by removing the latter four characters inorder to add the Distinct Number. For example, in the case where theoperating system OS(X) used at that time is the first operating systemOS(1) and the operating system OS(1) is MS-DOS, the Simple Name (1)consists of eight characters+three characters (extension) and the fourcharacters remained by removing four characters from the former eightcharacters (namely, top four characters) is set as a Distinct String.Incidentally, length of the Simple Name (X) differs depending on theoperating system OS(X), so that length of the Distinct String differsdepending on the operating system OS(X).

After generating the Distinct String, the CDRFS proceeds to step SP70 tocreate the Distinct Name (X) (=Distinct Name(1)) from the DistinctNumber and the Distinct String set at aforementioned steps SP65 andSP69. The Distinct Name (X) is created by arranging the Distinct Stringat the top portion and the Distinct Number next to the Distinct String.Incidentally, the Distinct Number is converted to be a String.

The initial value of the Distinct Number set at aforementioned step SP65is used in the Distinct Name (1) created as described above, whichprevents from coincident with the other file name. If, however, the useralready creates a file name through a operating system OS(X) by usingthe tilda mark ˜, there may exist a file name coincident. Thus the CDRFSproceeds to succeeding step SP71 to determine whether or not the createdDistinct Name (1) can be used (namely, the Distinct Name (1) coincideswith the other file name).

At this step SP71, the CDRFS searches all file names already createdwhether or not there exist any file name whose search key CRC coincidesand which has the tilda mark ˜ (namely, HT(1)=1) in the file entry readout from the CD-R disc DISC. At that time, the determination in whichthere exists coincident file makes the CDRFS compare the file nameitself so as to determine whether or not it coincides. As a result, ifthe file name coincides, the CDRFS obtains a negative result at stepSP71, and proceeds to step SP72 to add the Distinct Number (DNO) "1".

At that time, the change of the Distinct Number to new value causes thepossibility that there exists the Simple Name (1) having same DistinctNumber as the new Distinct Number on the operating system OS(X) (=OS(1))searched till then. Consequently, substituting the value X for thenumber Y, the CDRFS renews from the operating system OS(X) at startingof the search to the operating system OS(1) at operating, in which thesearch is started from the first operating system and executedthroughout the operating systems OS(1) to OS(N). In this manner, eachtime the coincident Distinct Name (X) is generated, the operating systemOS(X) is shifted to the OS(X) at operating so that the search isrepeated every operating system till the operating system OS(X) comesout again. This enables to surely search all the operating systems OS(1)to OS(N).

After finishing the process at step SP72, the CDRFS repeats theprocesses of aforementioned steps SP69, 70, 71 and 72 till the DistinctName (1) does not coincide. In this manner, Since the Distinct Number isrenewed till it does not coincide in the same operating system OS(X),the search time can be reduced considerably, comparing with the case ofreturning to the first operating system OS(X).

Here, if an affirmative result is obtained at step SP71, this shows thatthere exists no file name coincident with the Distinct Name (1) usingthe set Distinct Number and the Distinct Name (1) can be used. The CDRFSproceeds to step SP69 to add "1" to X so as to specify the secondoperating system OS(2). Further, at step SP75, the CDRFS compares thenumber X representing the present operating system OS(X) (=OS(2)) withthe value Y representing the operating system at starting which isrenewed at aforementioned step SP72. If they do not coincide with eachother, the CDRFS returns to aforementioned step SP67.

Consequently, at step SP67, the CDRFS examines the Name Conversion Flag(2) set corresponding to the operating system OS(2) so as to determinewhether or not the Simple Name (2) corresponding to the operating systemOS(2). If a negative result is obtained here, the CDRFS repeats theprocesses of steps SP69, SP70, SP71 and SP72 till the Distinct Name (2)of the operating system OS(2) does not coincide with the other filenames.

Then, if an affirmative result is obtained at step SP71, the CDRFSproceeds to step SP69 to add "1" to X, which changes the search objectto new operating system OS(3). At step SP75, the CDRFS determineswhether or not the operating system OS(3) is set as an operating systemOS(X) at starting at step SP72. The processes of steps SP69, SP70, SP71and SP72 are repeated till the operating system OS(X) which is set asthe operating system comes out again.

When finishing searching and setting the Distinct Name (X) for all theoperating systems OS(1) to OS (N), the CDRFS determines to use properlythe Simple Name (X) or the Distinct Name (X) created corresponding toeach operating system OS(1) to OS(N) based on the Name Conversion Flag(1) to the Name Conversion flag (N) set corresponding to which it isusable or unusable at step SP76, and set it in the file entry. Then theCDRFS finishes the file name conversion process. Thus the new file name(Object Name) specified by the operating system OS(0) and written in thefile entry the CD-R disc DISC at step SP1 is converted to the SimpleName (X) or the Distinct Name (X) by the CDRFS so as to be accessed wheneach operating system OS(1) to OS(N) accesses the file name.

Here, the detailed description of the search processes at aforementionedstep SP52 (FIG. 32) and step SP60 (FIG. 33) will be given below. Morespecifically, FIG. 35 shows the search process executed ataforementioned step SP52. The CDRFS converts a new file name receivedfrom the operating system OS to the search key CRC at step SP81, and, atnext step SP82, determines whether or not the search key CRC of the fileentry coincide with the search key CRC obtained at step SP81.

If an affirmative result is obtained here, the CDRFS proceeds to stepSP83 to compare the new file name received from the operating system OSwith all the existing file names written in the CD-R disc DISC. At thattime, the existing file names are read out via the file entry and areconverted to the form which is readable by the operating system OS whichspecifies the new file name.

Consequently, the file names are compared with each other at step SP83and are determined whether or not they coincide with each other. If anegative result is obtained here, the CDRFS proceeds to step SP87 todetermine that there in no same file name seeing from the presentoperating system OS. Then the CDRFS obtains a negative result at stepSP52 of FIG. 32 and proceeds to step SP54 (FIG. 32).

On the other hand, if a negative result is obtained at step SP82, thismeans that the search key CRC of the file name on the CD-R disc DISCread out via the file entry does not coincide with the search key CRC ofa new file name received from the operating system OS. At that time, theCDRFS proceeds to step SP54 of FIG. 32 via step SP87.

If an affirmative result is obtained at step SP84, this means that notonly the search key CRC but the file name itself coincide. At that time,the CDRFS proceeds to step SP85 to determine that there exists same filename as new file name seeing from the operating system OS. Then, theCDRFS proceeds to step SP53 of FIG. 32.

In this manner, since the CDRFS compares the file name itself with thenew file name merely whose search key CRC coincides, the search time canbe reduced comparing the case of comparing file name itself on all thefile name. In addition, the search processes shown in FIG. 35 areexecuted also similarly at step SP60 aforementioned about FIG. 33.

FIG. 36 shows details of the processes of searching the Distinct Name(X) at step SP71 aforementioned about FIG. 34. When the search key CRCof new file name coincides and a tilda mark ˜ is included, anaffirmative result is obtained at step SP91. In this case, only thecondition of both coincidence of the search key CRC and existence of thetilda mark can generates possibility of coincidence of file name, sothat the CDRFS proceeds to step SP93 via step SP92 to see the NameDiscipline. Further, the CDRFS determines corresponding Name ConversionFlag (X) from the Name Discipline at step SP94. If the determinationresult shows that the Simple Name (X) is already used, the CDRFSproceeds to step SP95 to compare whether or not the file name coincidesby using the Distinct Name. If the comparing result shows that there isno coincidence, the CDRFS obtains an affirmative result at step SP71aforementioned about FIG. 34 a nd proceeds to step SP69.

On the other hand, if the comparing result shows that there iscoincidence, the CDRFS obtains a negative result at step SP71aforementioned about FIG. 34 and proceeds to step SP72.

Further, if the determination result of the Name Conversion Flag (X) atstep SP94 of FIG. 36 shows that the Simple Name (X) can be used, theCDRFS proceeds to step SP96 to compare whether or not the file namecoincides by using the Simple Name (X). If the comparing result showsthat there is no coincidence, the CDRFS obtains an affirmative result atstep SP71 aforementioned about FIG. 34 and proceeds to step SP69.

On the other hand, if the comparing result at step SP96 shows that thereis no coincidence, the CDRFS obtains a negative result at step SP71aforementioned about FIG. 34 and proceeds to step SP72.

Further, if a negative result is obtained at step SP91 of FIG. 36, thismeans that the Distinct Name (X) created based on the new file name doesnot coincide with the file names already exist on the CD-R disc DISC. Atthat time, the CDRFS obtains an affirmative result at step SP71aforementioned about FIG. 34 via step SP94.

Next, the description will be made on the file name converting methodand concrete example of generation of the search key CRC.

In FIG. 37, the number given as the Distinct Number (DNO) is convertedto a String for using the Distinct Name (X). More specifically, theString shows the Distinct Number by numerals and alphabets and 0 to 9themselves in the Distinct Number consists the String. In addition, in10 to 36 in the Distinct Number, 10 is replaced with A of alphabet, 11is replaced with B of alphabet, and the following numbers to 36 aresuccessively replaced with alphabets. Thus 36 in the Distinct Numberbecomes Z of alphabet.

Further, 37 in the Distinct Number becomes a number of two FIGS. 00 as aString; 38 in the Distinct Number becomes a number 01 as a String; theDistinct Number increases one by one till 09 as a String. As a result,09 in the String is 46 in the Distinct Number. Further, 47 in theDistinct Number becomes 0A in a String; the Distinct Number increasesone by one alphabetically. Consequently, 36³ types of numbers can berepresented by the String of three figures consisting of number andalphabet.

The String formed in the manner described above is replaced with oradded to the latter characters of the Simple Name (X) createdcorresponding to each operating system OS(X), which generates theDistinct Name (X), as shown in FIG. 37.

In addition, the search key CRC is created in such a way as shown inFIG. 38 that first an extension of the file name to which the search keyCRC is added and depending on the position of "." included in the filename is divided. More specifically, when "." is positioned in the middleof the file name other than at the top or end of the file name,characters behind "." are treated as an extension of the file. Forexample, a file name "test." does not have any character behind ".", sothat this file name is regarded as having no extension. Also, with afile named "a.b.c.d", "d" is regarded as an extension of the file.

Next, the first four characters of Object Name are all converted tonumerals 0 to 9, capital letters of alphabet, or an underbar "₋₋ " inaccordance with the method as shown in FIGS. 39 and 40. For reference,the Object Names are all treated using unicode (Unicode) in the CDRFSSince the unicode represents all kinds of characters with a singlefixed-length code, a conversion between different characters can bereadily made.

For example, 0x30-0x39, 0x61-0x7a, and 0x41-0x5a, falling under a rangeof character codes 0≦X<128 of the unicode correspond to actualcharacters of "0"-"9", "a"-"z", "A"-"Z", and special symbols,respectively, as shown in FIG. 39. These character codes are convertedto "0"-"9", "A"-"Z", and "A"-"Z", respectively, while other charactercodes are converted to "₋₋ " (underbar). A conversion method as shown inFIG. 40 is applied to a range of character codes 128≦X≦65535 to convertall characters to numerals "0"-"9" or capital letters of alphabet"A"-"Z". As a result, a file name derived by converting Object Nameappears, for example, as shown in FIGS. 32 and 33.

As described above, for example, 2-byte characters such as Hiragana andKanji in Japanese or horizontally-enlarged characters are replaced with1-byte characters such as numerals and capital letters of alphabet, sothat in the process of creating the search key CRC, the conversionmethod according to the CDRFS can be used for the operating system OSused in the language environment except for Japanese (for example,English).

Further, the unicode cannot be used as the character code representingthe file name in, for example, the MS-DOS. When the file name consistsof Kanji or Hiragana, one Kanji is counted as two alphabets.Consequently, if the Distinct Name on the MS-DOS is created by the filename such as "" on the System 7.5, the file is "˜000".

Here, top four characters of the file name from the operating system OSis read in order to create the search key CRC, so that the search keyCRC is created according to "" on the System 7.5. On the contrary, onthe MS-DOS, it is created according to "˜0" on the MS-DOS, which makesthe search difficult. Accordingly, one Kanji is converted to twoalphabets by assuming that all the characters after 128 (0x0080) of theunicode needs 2 bytes although there are the characters which can showby one byte. The search key CRC created from the file "" on the System7.5 is created from "", i.e., "CUCW". The search key CRC created from"˜000" on MS-DOS is also created from "", i.e., "CUCW". As a result, twosearch keys CRC on the System 7.5 and on MS-DOS are same, which makesthe search possible. Incidentally, when less than four characterscomprises the Object Name, the search key CRC is created by adding anunderline mark (underbar) after the Object Name.

Here, an equation P(x) for calculating the search key may be given by agenerator polynomial expressed by the following equation:

    P(x)=x.sup.16 +x.sup.12 +x.sup.5 +1                        (13)

The search key CRC is set as shown in FIG. 43. In this case, a file namederived after converting Object Name, for example, "Abcd#123.efg" is"ABCD₋₋ 123₋₋ EFG", where a character string for conversion is "ABCD"and the search key CRC is "0x3b3a", as shown in FIG. 44. As describedabove, creation of the search key CRC by only four characters makes thesearch easier than the case of creation of the search key CRC by eightcharacters because the coincident of the characters decreases.

Also, in FIG. 44 when the Object Name consists of less than fourcharacters, for example "ab", a file name is converted to "AB " (spaceafter AB is blank), and two underlines (underbars) are added after theresulting character string to produce a character string for conversion"AB₋₋ ". As a result, the search key CRC using a cyclic code is"0xde7e". As described above, quite different search keys CRCs arederived even from similar file names, so that a file name can besearched easily.

Further, the search keys CRCs are made commonly usable on a plurality ofoperating systems OSs to eliminate the need for storing a large numberof search keys CRCs, thus making it possible to reduce a storagecapacity for the search keys. The information on the search keys CRCs,the Object Name, and the Distinct Name is stored in a file entry.

Incidentally, it is assumed that within attributes used in therespective operating systems OS(0), OS(1), OS(2), . . . , OS(N)registered in the CDRFS, those having the same characteristic are thesame. For example, when an attribute is asked on the operating systemOS(N), the CDRFS creates an attribute suitable for the operating systemOS(N) from an attribute flag of a file on the CD-R disc DISC andtransfers the attribute to the operating system OS(N). Similarly, whenan attribute is written for a file name from the operating system OS(N),this attribute is converted to an attribute flag which is then writteninto an associated file on the CD-R disc DISC. In this way, even if theuser determines an attribute to a file based on file specificationsmanaged only on the operating system OS(N), the file can be readilyreferenced irrespective of the specifications of each operating systemOS.

Explanation will be next given of how to actually create a new file onthe CD-R disc DISC in the CD-R disc apparatus 2 configured as describedabove. First, when a file creation instruction is issued from anapplication software AP to the operating system OS, a file creationinstruction for creating a file using a file name, for example,"ABCDEFGHIJK.TXT" on a currently running operating system OS(0) isissued to the CDRFS. The CDRFS searches files on the CD-R disc DISCthrough the CD-R drive 5 to see whether or not a file named"ABCDEFGHIJK.TXT" already exists thereon. The CDRFS checks the firstfour characters of each file name received from the operating systemOS(0) and compares file names of files having the same search key CRC.As a result of the comparison, if it is revealed that a file named"ABCDEFGHIJK.TXT" already exists on the CD-R disc DISC, the CDRFSnotifies the operating system OS that the same file name is alreadypresent, and terminates the file name conversion procedure as an inputerror.

Conversely, if no file named "ABCDEFGHIJK.TXT" is found on the CD-R discDISC on the operating system OS(0), the Object Name is written into theCD-R disc DISC. The CDRFS next writes a number corresponding to theoperating system OS(0) into the Name Dicipline of a file entry, and setsthe Name Conversion Flag (0) to "1". Here, it is determined whether ornot the Object Name includes "˜" (Tilda), and a HT Flag which is a flagindicative of the presence or absence of tilda is set to 1 or 0. In thisway, a file name conversion method is determined for creating a file onthe operating system OS(0).

Next, the file name is converted from the Object Name to the Simple Name(1) such that it can be accessed on the operating system OS(1), forexample, MS-DOS. Here, the file name of the Object Name is first reducedsimply to the form of eight characters plus three characters inconformity to MS-DOS to generate the Simple Name (1) "ABCDEFG.TXT".Then, files on MS-DOS are searched to see whether or not a file havingthe same file name is present. If no file having the same file name isfound, the Name Conversion Flag (1) is set to "1".

As a result, "ABCDEFG.TXT" is established as the Simple Name (1), sothat the file named "ABCDEFGHIJK.TXT" can be referenced from MS-DOS. Inthis event, if the Object Name includes characters or symbols whichcannot be used on MS-DOS, these characters or symbols are all replacedwith underbars "₋₋ ".

Conversely, if it is determined that a file named "ABCDEFG.TXT" alreadyexists on the CD-R disc DISC, the CDRFS sets the Name Conversion Flag(1) to "0". Subsequently, it is determined for each of other operatingsystems OS(2)-OS(N) registered as the operating system OS whether or nota file having the same Simple Name (X) is present. As a result, at thetime the number X exceeds the number of operating systems registered inthe OS 6, it is revealed from the determination results that the SimpleName (X) is usable on all operating systems OS(X) or the Simple Name (X)is not usable on any operating system OS(X).

If the Simple Name (X) is not usable on any operating system OS(X), theCDRFS generates Distinct String and String to set the Distinct Name (X).For setting the Distinct Name (X), "ABCDEFGHIJK.TXT" or the Object Nameis first assigned the Distinct Number as a unique number. Then, a flagof the Distinct Number associated with MS-DOS is set on for DistinctNumber and the file "ABCDEFGHIJK.TXT". The Distinct Name (X) in MS-DOSis created by adding a character string such as "˜0:" created inaccordance with the Object Number (here it is assumed to be "0") to theObject Name to have the number of characters complying with thespecifications of the operating system OS(X), i.e., MS-DOS, such as"ABCDEF˜0.TXT".

Next, it is determined whether or not a file having the same name as theDistinct Name (1) exists on MS-DOS. If a file named "ABCDEF˜0.TXT"exists on the CD-R disc DISC, the Distinct Number is incremented by oneto change the Distinct Name (1) to "ABCDEF˜1.TXT". Then, files on theCD-R disc DISC is searched to see whether or not a file named"ABCDEF˜1.TXT" is present on the CD-R disc DISC viewed from theoperating system OS(1). Subsequently, the Distinct Number is incrementeduntil no file having the same Distinct Name (1) is found on theoperating system OS(1), thus determining Distinct Name (1) which ends upto be a unique file name on the operating system OS(1).

As a result, it is determined whether the Distinct Name is used or theSimple Name is utilized when a file name is referenced on MS-DOS.

In the manner described above, Distinct Names are determined for Windows95 as the operating system OS(2), UNIX as the operating system OS(3),and so on following the Distinct Name created for the operating systemOS(1). Incidentally, the Simple Name is used when being usable for eachoperating system.

Also, when the Distinct Number is change d in the course of determininga reference method, a search is executed from a file name created on OSwhich imposes the most strict limitation on the number of characters.Specifically, within System7.X, Windows 95, UNIX, and MS-DOS, a searchis started with a file name created on MS-DOS. When reference methodsfor referencing a file name on all the operating Systems registered inthe CDRFS are determined as described above, the Distinct Number issimultaneously determined, so that Distinct Name is also determined.

For example, if the Distinct Number has eventually reached ten, theDistinct Name us ed for referencing "ABCDEFGHIJK.TXT" on MS-DOS ischanged to "ABCDEF˜A.TXT". The search key CRC, the Distinct Number, andthe Object Name thus determined are recorded in the file entry.

Also, for reading a file, the search method such as that found in theprocedure for determining a file name converting method can be used tosearch for a file required by the operating system OS. Further, fordeleting a file, the file itself can be located by the aforementionedsearch method, so that a file entry associated therewith may only bedeleted. This pointer also includes attributes, Object Name and so on ofthe file.

Further, for changing a file name, it is searched in accordance with thefile name conversion procedure whether or not a changed file name isused by any file on an associated operating system, in a manner similarto the creation of a file. Then, the Object Name is generated, file nameconversion methods are determined for all the operating systems OS(0),(1), (2) . . . , (N), and a subsequent file search is executed using theObject Name and the file name conversion methods.

According to the foregoing configuration, the CDRFS having a pluralityof operating systems OS(0), (1), (2) . . . , (N) registered therein setsa file name comprising Simple Name or Distinct Name universally adaptedto the respective specifications imposed by all the operating systemsOS(0), (1), (2) . . . , (N) in correspondence to the Object Name, sothat even if the user determines a name and/or an attribute for a filebased on file specifications managed only by, for example, the operatingsystem OS(0), a file name can be readily created for the file and thefile be accessed by any other operating systems OS(1), (2) . . . , (N),as shown in FIG. 45 (in the figure, OS(0) is assumed to be Macintosh),irrespective of the respective specifications imposed by all theoperating systems OS(0), (1), (2) . . . , (N).

As described above, since a file created by the CDRFS in conformity todifferent specifications imposed by any of different registeredoperating systems are assigned file names in conformity to thespecifications of the respective operating systems to permit the file tobe created and/or accessed without any inconvenience, the burden on theuser can be reduced, for example, when the CD-R disc DISC or the like isused as a removable storage medium, because the user is not required toperform operations for confirming an operating system which manages thestorage medium, and so on.

Also, since file names (Simple Name or Distinct Name) corresponding to aplurality of registered operating systems are generated when a file iscreated through conversion of Object Name, the file names can bestatically derived from the Object Name. In other words, it is possibleto prevent a file name from changing each time the file name isreferenced. Also, since a file name converting method is recordedinstead of recording file names corresponding to the respectiveoperating systems OS, the storage capacity can be reduced for managingthe file names.

Further, Simple Name or Distinct Name is generated by modifying part ofa character string forming the basic Object Name, so that the user canreadily predict the contents of a file from the file name since SimpleName or Distinct Name allows the user to quickly recognize the ObjectName which is the original file name.

Further, according to the aforementioned embodiment, when a plurality ofoperating systems OS(0), (1), (2) . . . , (N) are registered in a singlecomputer, the plurality of operating systems can be installed in thesame management region of a storage medium without partitioning themanagement region into dedicated subregions for each of the differentoperating systems having their own specifications, thus making itpossible to save the storage region. Also, when this file managementmethod is applied to a network server, the server need not have amanagement mechanism for each operating system.

Furthermore, according to the aforementioned embodiment, since the samefile can be used on all registered operating systems OSs, music softwareand video software such as multimedia CD need not be manufactured inconformity to each operating system OS, thus allowing the manufacturerto reduce a manufacturing cost. As a result, software, which has been sofar provided only in conformity to the specifications of one OS, can beutilized likewise by other types of operating systems OSs, therebyincreasing options of software, and preventing the user frominadvertently purchasing software for a different operating system.

Furthermore, according to the aforementioned embodiment, since methodfor universally adopted to all registered operating systems Oss and amulti-lingual scheme in correspondence to all language are employed, itis not necessary to convert a Japanese file name to a file name ofanother language even if a file created with a Japanese file name is tobe sent to a foreign country. Therefore, the present invention can alsobe utilized as file transfer means.

Here in the CD-R disc apparatus 1, the search method and the procedurefor determining a file name conversion method may be utilized to createa link file which can be used by all registered operating systems.Generally, a so-called link file contains file names of other fileswritten therein such that a file management program, upon receiving afile read instruction from an operating system OS, passes the contentsof a file, essentially desired by the operating system OS to reference,to the operating system OS based on the information written in the linkfile.

However, even if such a link file is created for a portable floppy diskwhich is used in changed operating system OS, the link file cannot beutilized by a plurality of operating systems because file names differfrom one operating system to another, thus causing a phenomenon, forexample, where a link file created by an operating system OS(A) can beutilized exclusively by the operating system OS(A), and a link filecreated by an operating system OS(B) can be utilized exclusively by theoperating system OS(B).

On the contrary, when such a link file is utilized in the CDRFS, a fileentry is referenced to determine on which operating system OS the linkfile was created, and a file name conversion method suitable for theoperating system, on which the file link was created, may be used toconvert a file name in the link file to specify a desired file. In thisway, the link file can be utilized on all registered operating systemsOSs.

Now, an example of a link file created on the operating system OS ofSystem 7.5 will be described. Assuming, for example, that a referencedfile is named "hijklmn" in a folder named "abcdefg", "abcdefg:hijklmn"is described in the link file for referencing the location of the file.In this event, since a file name written in lower case characters cannotused after the file management is transferred to MS-DOS in aconventional file management method, lower case characters in the foldername and the file name are converted to upper case characters, whereby"a file named hijklmn in a folder named abcdefg" is changed to "a filenamed HIJKLMN in a folder named ABCDEFG". Therefore, even if the linkfile is referenced, the link file will answer that such a file does notexist.

In this case, the file search method of the CDRFS is used to determinethat the link file was created on System 7.5. Then the file searchmethod is employed in order to determine the file name not by searchingthe file name on MS-DOS but by checking a file conversion flag of System7.5 on a file entry. Therefore it can be find out that "a file namedhijklmn in a folder named abcdefg" have been changed to "a file namedHIJKLMN in a folder named ABCDEFG". In this way, the contents of "a filenamed HIJKLMN type in a folder named ABCDEFG" can be returned to theoperating system.

While the foregoing embodiments have been described in connection withthe CD-R disc DISC, which is a write-once disc, as a storage medium, thepresent invention is not only limited to this, but can be applied to awide variety of general recording media, such as a floppy disk, CD(Compact Disc), and so on. Also, storage media other than disk-typeones, for example, card-type ones can also be used.

Also, while the foregoing embodiments have been described in connectionwith the CD-R disc DISC as a storage medium, the present invention isnot only limited to this, but also alternatively CD-ROM (CompactDisc-Read Only Memory) or the like, for example, can be used. In suchcase, CD-ROM can be accessed in the CD-R disc apparatus 1 from theoperating system OS through a CD-ROM device driver 30 (FIG. 1).

According to the present invention as described above, in an informationprocessing apparatus for accessing a file recorded on a recording mediumin conformity to specifications defined by a plurality of operatingsystems, means for converting a first file name based on thespecifications of an operating system used for file creation/file namechange to a second file name based on the specifications of an operatingsystem used for accessing the file is provided for all of the pluralityof operating systems, thereby file accesses among a plurality ofdifferent plurality of operating systems can be realized.

Also, according to the present invention, a file name converting step isprovided for converting a first file name set on any of the plurality ofoperating system to second file names corresponding to thespecifications of all of the plurality of operating systems at the timeof accessing a file recorded on a recording medium in conformity tospecifications defined by the plurality of operating systems. Thereforeit becomes possible to simplify the file access among a plurality ofdifferent operating systems having different specifications.

Industrial Usability

The present invention can be utilized to a system for processinginformation and recording it on a recording medium, for example aninformation processing apparatus using a write-once disc type ofrecording medium.

What is claimed is:
 1. A file name conversion method, in an informationprocessing apparatus having a recording medium with recorded file namesthereon and operating by at least a first operating system, the methodfor converting a first file name which can be distinguished by saidfirst operating system to a second file name which can be distinguishedby both the first operating system and at least a second operatingsystem, comprising:a step for transferring said first file name fromsaid first operating system; a first same file name searching step forsearching whether or not there exists said first file name on saidrecording medium; a first file name writing step for writing said firstfile name on said recording medium in the case where no same file nameis found at said first same file name searching step; a first file nameconversion step for converting said first file name to a third file namein correspondence to both said first operating system and said secondoperating system; a second same file name searching step for convertingthe file name in conformity with said second operating system andsearching whether or not the file name exists on said recording medium;and a step for assuming said third file name as said second file name inthe case where no same file name is found at said second same file namesearching step.
 2. The file name conversion method according to claim 1,comprising the steps of:deleting characters of said first file namewhich exceeds the number of characters permitted in said secondoperating system and creating a permitted file name; and replacing thecharacters in said permitted file name which are not permitted on saidsecond operating system to permissive characters and creating said thirdfile name.
 3. The file name conversion method according to claim 2,whereinsaid replacing step replaces characters which are not usable onsaid second operating system out of the characters of said permittedfile name with underbars.
 4. The file name conversion method accordingto claim 1, comprising the step of:terminating the file name conversionby outputting an error signal when said first same file name searchingstep finds same file name.
 5. The file name conversion method accordingto claim 1, further comprising the steps of:converting characters usedin said first file name to numbers, capital letter of alphabets, orunderbars based on character code assigned to each character of saidfirst file name; extracting a predetermined number of characters fromtop of said converted file name so as to generate an extracted filename; generating a search key based on character code of each characterof said extracted file name; and recording said search key on saidrecording medium.
 6. The file name conversion method according to claim5, wherein said first same file name searching step comprises the stepsof:converting the characters used in said first file name to numbers,capital letter of alphabets, or underbars based on character codeassigned to each character of said first file name; extracting apredetermined number of characters from top of said converted file nameso as to generate an extracted file name; generating a second search keybased on character code of each character of said extracted file name;and determining whether or not said second search key and said searchkey recorded on said recording medium are same and outputting thedetermination result.
 7. The file name conversion method according toclaim 6, comprising the steps of:in the case of outputting thedetermination result that said second search key and said search keyrecorded on said recording medium at said determination resultoutputting step, deleting characters of said first file name whichexceeds the number of characters permitted in said second operatingsystem and creating a permitted file name; replacing the characters insaid permitted file name which are not permitted on said secondoperating system to permissive characters and creating said third filename; and assuming said third file name as said second file name.
 8. Thefile name conversion method according to claim 5, wherein said secondsame file name searching step comprises the steps of:converting thecharacters used in said third file name to numbers, capital letter ofalphabets, or underbars based on character code assigned to eachcharacter of said third file name; extracting a predetermined number ofcharacters from top of said converted file name so as to generate anextracted file name; generating a second search key based on charactercode of each character of said extracted file name; and determiningwhether or not said second search key and said search key recorded onsaid recording medium are same and outputting the determination result.9. The file name conversion method according to claim 1, comprising:inthe case of finding same file name at said second same file namesearching step, second conversion step for converting said first filename to said fourth file name so as to correspond to at least saidsecond operating system; and a step for assuming said fourth file nameas said second file name.
 10. The file name conversion method accordingto claim 9, wherein said second same file name conversion stepcomprises:a conversion number setting step for searching the numberwhich is not used in said second file name conversion step and settingsaid number not used as an initial number; a conversion step forconverting said number to alphabets and numbers in accordance with apredetermined rule; a creating step for creating a fourth file name byreplacing at least a part of characters of said third file name withsaid alphabets and numbers; a third same file name searching step forsearching whether or not there exists said fourth file name on saidrecording medium seeing through said second operating system; and arepeating step for repeating said conversion step, said creating step,and said third same file name searching step assuming that said numberto which a predetermined number is added is said number when same filename is found.
 11. A file name conversion method, in an informationprocessing apparatus having a recording medium with recorded file namesthereon and operating by at least a first operating system, the methodfor converting a first file name which can be distinguished by saidfirst operating system to a second file name which can be distinguishedby both the first operating system and at least a second operatingsystem, comprising:a step for transferring said first file name fromsaid first operating system; a first same file name searching step forsearching whether or not there exists said first file name on saidrecording medium; a first file name writing step for writing said firstfile name on said recording medium in the case where no same file nameis found at said first same file name searching step; a first file nameconversion step for converting said first file name to a third file namein correspondence to both said first operating system and said secondoperating system; a second same file name searching step for convertingthe file name in conformity with said second operating system andsearching whether or not the file name exists on said recording medium;and a step for assuming said third file name as said second file name inthe case where no same file name is found at said second same file namesearching step; wherein, in the case of finding the same file name atsaid second same file name searching step, the method further comprises:a second conversion step for converting said first file name to a fourthfile name in correspondence to both said first operating system and atleast said second operating system; a third same file name searchingstep for searching whether or not there exists said fourth file name onsaid recording medium; a step for assuming said fourth file name as saidsecond file name; and an operating system discrimination numberrecording step for recording an operating system discrimination numberfor discriminating which operating system is the second operating systemwhen the same file name is found at said third same file name searchingstep.
 12. The file name conversion method according to claim 11, whereinsaid second conversion step comprises:a conversion number setting stepfor searching for a number which is not used in said second file nameconversion step and setting said not used number as an initial number; aconversion step for converting said initial number to alphabets andnumbers in accordance with a predetermined rule; and a creating step forcreating a fourth file name by replacing at least a part of thecharacters of said third file name with said alphabets and numbers, andwhereinsaid predetermined rule is presented by the following equations;if said initial number is 0 to 35: said alphabets and numbers=m[DNO mod36] if said initial number is 36 to 1331:the first figure of saidalphabets and numbers=m[(DNO-36) mod 36] the second figure of saidalphabets and numbers=m[(DNO-36)/36] if said initial number is 1332 to47988:the first figure of said alphabets andnumbers=m[((DNO-1332)-((DNO--1332) mod 1296)) mod/36] the second figureof said alphabets and numbers=m[((DNO-1332)-((DNO-1332) mod 1296))/36]the third figure of said alphabets and numbers m[(DNO-1332)/1296]provided that, m[X] represents x-th character of the"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ" and X mod Y represents theremainder when X is divided by Y.
 13. The file name conversion methodaccording to claim 1, further comprising the steps of:convertingcharacters used in said first file name to numbers, capital letter ofalphabets, or underbars based on character code of each character ofsaid first file name; extracting a predetermined number of charactersfrom top of said converted file name so as to generate an extracted filename; generating a search key based on character code of each characterof said extracted file name; recording said search key on said recordingmedium; determining whether or not the file name on said recordingmedium contains a tilda mark so as to output the determination result;and recording said determination result on said recording medium. 14.The file name conversion method according to claim 1, wherein said thirdsame file name searching step comprises the steps of:converting thecharacters used in said first file name to numbers, capital letter ofalphabets, or underbars based on character code assigned to eachcharacter of said fourth file name; extracting a predetermined number ofcharacters from top of said converted file name so as to generate anextracted file name; generating a second search key based on charactercode of each character of said extracted file name; determining thatthere is not said fourth file name on said recording medium when saidsecond search key and said search key recorded on said recording mediumare not same as a result of comparing; reading the determination resultwhether or not said tilda mark is contained when said second search keyand said search key recorded on said recording medium are same as aresult of comparing; and determining that there is said fourth file nameis not recorded on said recording medium when said reading step findsthat a file name shown by said search key which is recorded on saidrecording medium does not contain said tilda mark.
 15. A file nameconversion method, in an information processing apparatus having arecording medium with recorded file names thereon and operating by atleast a first operating system, the method for converting a first filename which can be distinguished by said first operating system to asecond file name which can be distinguished by both the first operatingsystem and at least a second operating system, comprising:a step fortransferring said first file name from said first operating system; afirst same file name searching step for searching whether or not thereexists said first file name on said recording medium; a first file namewriting step for writing said first file name on said recording mediumin the case where no same file name is found at said first same filename searching step; a first file name conversion step for convertingsaid first file name to a third file name in correspondence to both saidfirst operating system and said second operating system; a second samefile name searching step for converting the file name in conformity withsaid second operating system and searching whether or not the file nameexists on said recording medium; a step for assuming said third filename as said second file name in the case where no same file name isfound at said second same file name searching step; and a discriminationnumber writing step for writing an operating system discriminationnumber for discriminating which operating system said first operatingsystem is on said recording medium.
 16. The file name conversion methodaccording to claim 15, further comprising the steps of:recording thesearch result obtained at said second same file name searching step onsaid recording medium.
 17. An information processing apparatus forconverting a first file name which can be distinguished by a firstoperating system to a second file name which can be distinguished byboth the first operating system and at least a second operating system,comprising:storing means for storing a first operating system therein;input means for inputting a file name therein from said first operatingsystem; first same file name searching means for searching whether ornot there exists said first file name on said recording medium; firstfile name writing means for writing said first file name on saidrecording medium in the case where no same file name is found by saidfirst same file name searching means; first file name conversion meansfor converting said first file name to a third file name incorrespondence to both said first operating system and a secondoperating system; converting means for converting said third file nameto a fourth file name in conformity with both said first operatingsystem and said second operating system; second same file name searchingmeans for searching whether or not said fourth file name exists on saidrecording medium; and means for assuming said third file name as saidsecond file name in the case where no same file name is found by saidsecond same file name searching means.
 18. A file name conversionmethod, in an information processing apparatus having a recording mediumwith recorded file names thereon and operating by at least firstoperating system, the method for converting a first file name which canbe distinguished by said first operating system to a second file namewhich can be distinguished by both the first operating system and atleast a second operating system, comprising the steps of:inputting afirst file name from said first operating system; converting thecharacters used in said file name to numbers, capital letter ofalphabets, or underbars based on a character code assigned to eachcharacter of said file name; extracting a predetermined number ofcharacters from the top of said converted file name so as to generate anextracted file name; and converting said extracted file name to a searchkey based on the character code of each character of said extracted filename.
 19. A recording medium, in an information processing apparatushaving recording medium with recorded file names thereon and operatingby at least a first operating system, on which is recorded a file nameconversion program for converting a first file name which can bedistinguished by said first operating system to a second file name whichcan be distinguished by both the first operating system and at least asecond operating system, comprising:a step for transferring a first filename from said first operating system; a first same file name searchingstep for searching whether or not there exists said first file name onsaid recording medium; a first file name writing step for writing saidfirst file name on said recording medium in the case where no same filename is found at said first same file name searching step; a first filename conversion step for converting said first file name to a third filename in correspondence to both said first operating system and saidsecond operating system; a second same file name searching step forsearching whether or not the third file name exists on said recordingmedium; and a step for assuming said third file name as said second filename in the case where no same file name is found at said second samefile name searching step.